In the module warnings, there is no function for
removing certain items from the list of warnings
filters.  The only options are to empty the list
completely or to manipulate the warnings.filters list
directly, both of which is unfortunate in my opinion.

I attached a file with a removefilter() function.  I
don't know how safe it is to complete regular
expressions, however, it works nicely for me.

Logged In: YES 
user_id=1188172

I don't know, but wouldn't it be simpler to just document
the warnings.filters attribute so that people know how to
manipulate the list of filters?

Logged In: YES 
user_id=442234

It's simpler of course.  However, if it's relatively easy to
avoid, a module user should not manipulate module data
structures directly, I think.

Logged In: YES 
user_id=6656

Pfft, this isn't Java!

I'm not sure it should be done with impunity, but as a documented 
interface it makes perfect sense to me.

Logged In: YES 
user_id=80475

I'm concerned that removefilter() may not work well in the 
presence of multiple modules that use the warnings module.  It 
may be difficult to make sure the one removed wasn't 
subsequently added another module.  Also, the issue is 
compounded because the order of filter application is important.

Logged In: YES 
user_id=1140166

ISTM the most common use case for this would be to set up
some filter, perform some operation, then remove the filter.
 In this case, the removal wouldn't be far from the
insertion, so it might not be unreasonable to keep around a
reference to the added filter and remove it by identity when
it's no longer needed ... if such a reference were available
that is!  As it stands, one does not get back a reference to
the filter tuple added by filterwarnings(), so the only
options left are to immediately grab warnings.filters[0], or
construct one's own filter tuple manually (yech!).  Some way
should be provided to work in this case at least.

As an aside, with 2.5's proposed context managers, a filter
context could be added to this module so that a filter could
be added and removed around the operation with a 'with' block.

Logged In: YES 
user_id=80475

Whether or not the use case is common is irrelevant if the
solution is laced with problems (we don't add "works most of
the time" functions).  Am rejecting the removefilter()
proposal.  It doesn't scale-up for complex programs with
multiple modules each using their own warning filters.  It
is too easy for innocuous looking code to violate another
module's invariants.  This is doubly true in a
multi-threaded environment.

+1 on the proposal for a Py2.5 context manager solution. 
That proposal is workable because the CM can specifically
id() the filter that it added and later remove that exact
entry if still present -- this will work even other modules
have loaded an equivalent filter.  To work in a threaded
environement, the removal sequence should use a lock.

Closing. We now have a context manager based solution for saving, changing and restoring warning filters.

http://docs.python.org/library/warnings.html#testing-warnings

(I just came across this issue looking for such a solution. :-)