[Python-Dev] Py3k DeprecationWarning in stdlib (original) (raw)

Brett Cannon brett at python.org
Wed Jun 25 19🔞55 CEST 2008

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.testsupport test.testsupport.catchwarning(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.catchwarning() 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 protectwarningsmodule, and then catchwarnings to record the warnings. The catchwarnings context manager could reuse the protectwarningsmodule one. "with protectwarningsmodule:" seems easier to understand (and document) than "with catchwarning(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

More information about the Python-Dev mailing list