[Python-Dev] Py3k DeprecationWarning in stdlib

[Brett Cannon]

On Wed, Jun 25, 2008 at 6:08 AM, Andrew Bennetts
<andrew-pythondev at puzzling.org> wrote:
> 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.
>

The 'record=False' functionality was only added a couple of months
ago. The context manager was originally written to help test the
warnings module itself, so it was not meant to allow warnings to
propagate. I tossed in the 'record' argument so that I could mutate
the warnings filter.

> 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?
>

If you want, but Benjamin plans to undocument this for users along
with all other test.support stuff (which I agree with). Most of the
APIs in test.support were just quickly written and have not
necessarily been thought through in order to make sure that the APIs
makes sense (like in this case).

-Brett