-
-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
resetwarnings doesn't reset warnings registry #65923
Comments
There seems to be no (official) way to reset the warnings registry; in particular, resetwarnings() doesn't reset it. It makes it difficult to get repeatable warning messages, e.g. at the command prompt, because the shortcut path will silence messages which were already emitted, even if the filter have been changed to "always" in-between. |
This could be related to bpo-4180. |
Related indeed, though not exactly the same issue. What I'd like is to reset (i.e. clear) the registry even when keeping the default warning scheme. |
This can be quite painful to work around, since the warning registry is scattered all over. See, e.g., https://github.com/scikit-image/scikit-image/blob/master/skimage/_shared/_warnings.py#L9 |
I'm not sure how generally applicable this is, but it might be useful as a starting point: Attached is a bit of code I've been using: it's a reset_warnings_registry() context manager, which backs up & clears the registry state for the duration of the context, then restores it afterwards. It's particularly useful for unittests, just create & call the __enter__() method during setUp(), and attach __exit__() via addCleanup. Each test is then gets it's own isolated warnings registry. |
Just ran into this myself -- not sure what the intended fix is (hopefully it's "add a function that restores the warnings configuration to its defaults?" Changing resetwarnings seems likely to be not doable I assume.) But in the meanwhile, is a doc patch acceptable? The current documentation for resetwarnings is really deceptive, and makes it look like it does what @pitrou (and I) thought it did:
Compare to the docstring of the function (and to what it actually does):
But there are still too many implementation details of the warnings module leaking through here -- for end users it's just "restore the warnings configuration to its defaults" (what it looks like resetwarnings should do) or "unfilter all warnings, even beyond the filters configured by default" (what it actually does). Is at least making the docs reflect the latter a reasonable patch to submit, to start, while what to do about the former is thought about? |
@Julian Am leaning more into us applying a relevant fix, than adjusting the documentation. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: