This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: resetwarnings doesn't reset warnings registry
Type: behavior Stage:
Components: Documentation Versions: Python 3.10, Python 3.9, Python 3.8, Python 3.7, Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Arfrever, Julian, berker.peksag, docs@python, eli.collins, eric.snow, nanjekyejoannah, ncoghlan, pitrou, robertmuil, stefanv
Priority: normal Keywords:

Created on 2014-06-11 16:11 by pitrou, last changed 2022-04-11 14:58 by admin.

Files
File name Uploaded Description Edit
reset_warning_registry.py eli.collins, 2015-07-26 15:14 reset_warning_registry() context manager
Messages (7)
msg220282 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-06-11 16:11
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.
msg220328 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2014-06-12 02:06
> 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 issue 4180.
msg220517 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-06-14 01:07
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.
msg220547 - (view) Author: Stefan van der Walt (stefanv) Date: 2014-06-14 10:46
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
msg247432 - (view) Author: Eli Collins (eli.collins) * Date: 2015-07-26 15:14
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.
msg369809 - (view) Author: Julian Berman (Julian) * Date: 2020-05-24 16:40
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:

> Reset the warnings filter. This discards the effect of all previous calls to filterwarnings(), including that of the -W command line options and calls to simplefilter().

Compare to the docstring of the function (and to what it actually does):

> """Clear the list of warning filters, so that no filters are active."""

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?
msg404890 - (view) Author: Joannah Nanjekye (nanjekyejoannah) * (Python committer) Date: 2021-10-23 15:56
@Julian Am leaning more into us applying a relevant fix, than adjusting the documentation.
History
Date User Action Args
2022-04-11 14:58:04adminsetgithub: 65923
2021-10-23 21:12:30yaubisetnosy: - yaubi
2021-10-23 15:56:10nanjekyejoannahsetnosy: + nanjekyejoannah
messages: + msg404890
2020-05-24 16:40:34Juliansetversions: + Python 3.6, Python 3.7, Python 3.8, Python 3.9, Python 3.10
nosy: + Julian, docs@python

messages: + msg369809

assignee: docs@python
components: + Documentation
2020-03-18 18:03:59brett.cannonsetnosy: - brett.cannon
2015-07-26 15:14:03eli.collinssetfiles: + reset_warning_registry.py
nosy: + eli.collins
messages: + msg247432

2014-11-14 02:10:03Arfreversetnosy: + Arfrever
2014-11-10 11:19:22robertmuilsetnosy: + robertmuil
2014-07-29 01:26:36yaubisetnosy: + yaubi
2014-06-14 10:46:25stefanvsetnosy: + stefanv
messages: + msg220547
2014-06-14 01:07:32pitrousetmessages: + msg220517
2014-06-12 02:06:29berker.peksagsetnosy: + berker.peksag
messages: + msg220328
2014-06-11 16:11:44pitroucreate