Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

MAINT: don't format logs in log call.#25073

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
jklymak merged 2 commits intomatplotlib:mainfromCarreau:log-f
Jan 25, 2023
Merged

Conversation

Carreau
Copy link
Contributor

@CarreauCarreau commentedJan 25, 2023
edited
Loading

In particular f-string:

There are many reason not to use f-string in logs,

But also % formatting in a couple of places.

PR Checklist

Documentation and Tests

  • Has pytest style unit tests (andpytest passes)
  • Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).
  • New plotting related features are documented with examples.

Release Notes

  • New features are marked with a.. versionadded:: directive in the docstring and documented indoc/users/next_whats_new/
  • API changes are marked with a.. versionchanged:: directive in the docstring and documented indoc/api/next_api_changes/
  • Release notes conform with instructions innext_whats_new/README.rst ornext_api_changes/README.rst

In particular f-string:There are many reason not to use f-string in logs, - F-strings are eager, so might be slow. So this may affect performance   (we can filter before formatting). - prevent structured logging or handler to highlight. - Security (untrusted input can lead to DOS on formatting,https://discuss.python.org/t/safer-logging-methods-for-f-strings-and-new-style-formatting/13802)But also % formatting in a couple of places.
Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
@story645
Copy link
Member

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

@jklymakjklymak merged commitaaf01bf intomatplotlib:mainJan 25, 2023
@jklymak
Copy link
Member

@meeseeksdev backport to 3.7.0

@jklymakjklymak added this to thev3.7.0 milestoneJan 25, 2023
@lumberbot-app
Copy link

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

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

@jklymak
Copy link
Member

@meeseeksdev backport to 3.7.x

@lumberbot-app
Copy link

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

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

@jklymak
Copy link
Member

@meeseeksdev backport to v3.7.x

@lumberbot-app
Copy link

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.xgit pull
  1. Cherry pick the first parent branch of the this PR on top of the older branch:
git cherry-pick -x -m1 aaf01bf0918d6d072a9824581aa3e5bccf1ad7e0
  1. 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."
  1. Push to a named branch:
git push YOURFORK v3.7.x:auto-backport-of-pr-25073-on-v3.7.x
  1. 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 theStill Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free tosuggest an improvement.

@jklymak
Copy link
Member

@Carreau is this important enough to manually backport?

@ksunden
Copy link
Member

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

@jklymak
Copy link
Member

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

@greglucas
Copy link
Contributor

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

@tacaswell
Copy link
Member

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

greglucas reacted with thumbs up emoji

@Carreau
Copy link
ContributorAuthor

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.

greglucas and story645 reacted with thumbs up emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@QuLogicQuLogicQuLogic approved these changes

@jklymakjklymakjklymak approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.8.0
Development

Successfully merging this pull request may close these issues.

7 participants
@Carreau@story645@jklymak@ksunden@greglucas@tacaswell@QuLogic

[8]ページ先頭

©2009-2025 Movatter.jp