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: filterwarnings('error') has no effect
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: ajaksu2, brett.cannon, georg.brandl, marienz, rupole
Priority: normal Keywords:

Created on 2006-08-29 07:27 by rupole, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
test_warnings.py rupole, 2006-08-29 07:27
Messages (9)
msg29701 - (view) Author: Roger Upole (rupole) Date: 2006-08-29 07:27
Once a warning has already been issued, 
warnings.filterwarnings('error',...) will not cause an 
error to be raised.  When the attached script is run, 
the warning is printed the first time thru the loop, 
but no error is raised the 2nd time thru.  Likewise, 
warnings.filterwarnings('always',...) will not cause 
the warning to be printed again.

msg29702 - (view) Author: Marien Zwart (marienz) * Date: 2006-08-31 20:34
Logged In: YES 
user_id=857292

This is caused by the warnings module caching when a
combination of message, Warning subclass and linenumber gets
ignored and bypassing the search through the warning filters
when that same combination occurs again.

I think it is possible to avoid this problem while keeping
the cache by keeping track of the "version" of the filters
list (a simple integer that is incremented every time the
filters list is modified through the functions in the
warnings module) and including this in the key tuple
warn_explicit uses to remember previous ignores. Old stuff
would remain in the cache but that should not be a big
problem (changes to the filters list should not be that common).

Does this sound reasonable? If it does I'll see if I can
produce a patch.
msg29703 - (view) Author: Roger Upole (rupole) Date: 2006-09-01 04:38
Logged In: YES 
user_id=771074

It might be simpler to check if the warning is in the line 
cache after the disposition is determined from the filters.
In the case of 'always' and 'error', there's no need to 
check the cache at all.
msg29704 - (view) Author: Marien Zwart (marienz) * Date: 2006-09-01 10:44
Logged In: YES 
user_id=857292

The whole point of that cache is to not go through the list
of filters if the warning is in the cache. Why would you
keep the cache around if you search through the filters in
every case anyway?
msg29705 - (view) Author: Roger Upole (rupole) Date: 2006-09-01 17:19
Logged In: YES 
user_id=771074

Without the cache, the only filters you could possibly 
implement would be 'error' and 'ignore'.
msg29706 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-09-06 06:22
Logged In: YES 
user_id=849994

You could go another way and check/cleanup the cache on each
call to filterwarning().
msg29707 - (view) Author: Roger Upole (rupole) Date: 2006-09-06 10:52
Logged In: YES 
user_id=771074

That depends on how it's expected to behave when switching 
back to a filter that actually needs to check the cache.  
Should 'once' mean only one time ever, or should it print 
the warning again after the filters are modified ?
If the cache is cleaned up, there's no way to know if the 
warning was issued prior to the modification.
msg81699 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-02-12 01:02
Confirmed in trunk.
msg83452 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-03-11 02:24
At this point the warnings module has been working as it is for so long
that this is not going to be able to change without a lot of pain for
people.
History
Date User Action Args
2022-04-11 14:56:19adminsetgithub: 43909
2009-03-11 02:24:48brett.cannonsetstatus: open -> closed

messages: + msg83452
resolution: wont fix
2009-02-12 01:02:12ajaksu2setnosy: + ajaksu2
messages: + msg81699
stage: needs patch
2009-02-11 03:09:10ajaksu2setassignee: brett.cannon
versions: + Python 2.6, - Python 2.5
type: behavior
components: + Library (Lib), - None
nosy: + brett.cannon
2006-08-29 07:27:59rupolecreate