Can a note about this be put somewhere on the contributing code page? I worry that this is the type of thing that will get changed in either direction 16 times.

@meeseeksdev backport to 3.7.0

Something went wrong ... Please have a look at my logs.

It seems that the branch you are trying to backport to does not exist.

@meeseeksdev backport to 3.7.x

Something went wrong ... Please have a look at my logs.

It seems that the branch you are trying to backport to does not exist.

@meeseeksdev backport to v3.7.x

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.7.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 aaf01bf0918d6d072a9824581aa3e5bccf1ad7e0

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am "Backport PR #25073: MAINT: don't format logs in log call."

4. Push to a named branch:

git push YOURFORK v3.7.x:auto-backport-of-pr-25073-on-v3.7.x

5. Create a PR against branch v3.7.x, I would have named this PR:

"Backport PR #25073 on branch v3.7.x (MAINT: don't format logs in log call.)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

@Carreau is this important enough to manually backport?

I didn't go back to find these lines specifically, but most of these are likely made into f strings via #24980 which was not itself backported to 3.7.x

Ah.... It did all seem too obscure to have triggered conflicts. So I think this can safely not be backported.

This may conflict with the f-string PR, but that PR only changed from .format() to f"{}" in the log calls, so we were already previously doing it poorly with the str.format(val). This is an improvement and uses the logger formatting, not str % val but rather log(str, val). I don't think it would be super hard to manually backport if @Carreau wants to tackle it.

Given it was non ideal before (and probably has been for a while) I do not think backporting is a high-priority.

I agree it's not critical to backport.

It can be put on the style guide, there is also a pylint item that detect some of those usage.
But again I don't think it is critical.

Mostly it's giving the right example, so it has more chances of not being copy/pasted somewhere else.