[Python-Dev] Py3k DeprecationWarning in stdlib

Andrew Bennetts andrew-pythondev at puzzling.org
Wed Jun 25 15:08:57 CEST 2008

Nick Coghlan wrote:
> I forgot this had already been added to the Python regression test  
> machinery, so it will just be a matter of updating the relevant tests to  
> use it:

That's a nice surprise!  I'm glad the standard library is growing facilities
like this.

I think it could be improved a little, though:

> http://docs.python.org/dev/library/test.html#module-test.test_support
> test.test_support.catch_warning(record=True)¶
>     Return a context manager that guards the warnings filter from being  
> permanently changed and records the data of the last warning that has  
> been issued. The record argument specifies whether any raised warnings  
> are captured by the object returned by warnings.catch_warning() or  
> allowed to propagate as normal.

The description doesn't really make the record=False case clear.  This context
manager is doing two different jobs: 1) restore the filters list and showwarning
function to their original state when done, and 2) optionally (if record=True)
record the last warning in the "as" target.  That feels a bit weird.

I think a clearer way to provide that functionality would be with two separate
context managers: one that copies and finally restores the filters list and
showwarnning function called protect_warnings_module, and then catch_warnings to
record the warnings.  The catch_warnings context manager could reuse the
protect_warnings_module one.  "with protect_warnings_module:" seems easier to
understand (and document) than "with catch_warning(record=False)".

Should I file a bug for this?

>     The context manager is typically used like this:
>     with catch_warning() as w:
>         warnings.warn("foo")
>         assert str(w.message) == "foo"

Maybe this is a YAGNI, but what if an expression triggers multiple warnings?
Perhaps the WarningMessage object ought to keep a list rather than just the last

Another thought: if the warnings module had a public, documented way to
manipulate the filter list (e.g. warnings.get_all_filters() and
warnings.set_all_filters(...)), then people could build these sorts of test
facilities for themselves if the test_support one turns out to be too limiting
or otherwise a poor fit. 


More information about the Python-Dev mailing list