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 warning. 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. -Andrew. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
