Issue3780
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2008-09-04 21:59 by exarkun, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (8) | |||
---|---|---|---|
msg72530 - (view) | Author: Jean-Paul Calderone (exarkun) * ![]() |
Date: 2008-09-04 21:59 | |
In Python 2.5 and earlier, the `warnings.warn_explicit` function could be replaced in order to test what warnings were emitted by some code. This allowed unit tests for warnings to be written. Since much of the warnings module was re-implemented in C, replacing `warnings.warn_explicit` no longer has any effect. This, together with the fact that there are no other public APIs for hooking into the warning system with duplication suppression disabled means that there is no reliable way to write unit tests for warnings. This was previously discussed on python-dev, but no conclusion was reached. See http://mail.python.org/pipermail/python-dev/2008-June/080635.html and the follow-ups. For Twisted, the consequence of this is roughly 79 failing unit tests in Python 2.6b3 and no clear way to fix them, except to stop using the standard library warnings module. |
|||
msg72532 - (view) | Author: Benjamin Peterson (benjamin.peterson) * ![]() |
Date: 2008-09-04 22:08 | |
Would the new catch_warnings [1] context manager help in this regard? [1] http://docs.python.org/dev/library/warnings.html#warnings.catch_warnings |
|||
msg72536 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2008-09-04 22:36 | |
It sounds like you are trying to get around "once"/"default" rules to see all warnings raised. Why can't you use catch_warnings() and do ``simplefilter("always")`` or use "error"? Otherwise you can force the importing and use of the pure Python implementation of warnings if you really want to continue to use your hacked version of warn_explicit (see test_warnings on how to control whether the C implementation gets used or not). |
|||
msg72540 - (view) | Author: Jean-Paul Calderone (exarkun) * ![]() |
Date: 2008-09-04 22:47 | |
I was aware of it, but I didn't realize adding an "always" filter would make sure all warnings always got noticed. I haven't tried changing Twisted's use of the warnings module yet, but it looks like `catch_warnings` will work here. |
|||
msg72541 - (view) | Author: Glyph Lefkowitz (glyph) ![]() |
Date: 2008-09-04 22:48 | |
Looks like we just misunderstood the way the warnings filter works, and catch_warnings' interaction with it. Thanks for the priority bump, guido, and sorry for the false alarm! |
|||
msg72548 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2008-09-04 22:58 | |
On Thu, Sep 4, 2008 at 3:48 PM, Glyph Lefkowitz <report@bugs.python.org> wrote: > > Glyph Lefkowitz <glyph@divmod.com> added the comment: > > Looks like we just misunderstood the way the warnings filter works, and > catch_warnings' interaction with it. Thanks for the priority bump, > guido, and sorry for the false alarm! > If there is a doc problem, please suggest some better wording! I tossed the text together the best I could but if it needs improvement I welcome suggestions. |
|||
msg72553 - (view) | Author: Glyph Lefkowitz (glyph) ![]() |
Date: 2008-09-04 23:17 | |
The use of the term "filter" is pretty confusing. I would normally say it was just me, but a bunch of other Twisted hackers seemed to interpret it the same way: a "filter" is something that has an opportunity to remove something else. For example, the python builtin function "filter". Experimentation with the filters list seems to confirm this impression, since later filters do not have an opportunity to access the warnings that earlier filters have removed. The intuitive leap there is to assume that inserting a filter at the head of the list won't do anything different than inserting it at the tail, since a later filter will remove it. I can't think of an obvious recommendation to improve the text for the filter system itself, because upon reading it in more depth, it's fairly clear. Maybe the heading could be changed to something more like "intercepting warnings" or "controlling the way that warnings are emitted"? Something attention-grabbing that describes its purpose and doesn't use the word "filter". Even a sub-heading which simply described how to use 'always' filter to cause every warning to be emitted would be helpful. The biggest improvement to the documentation for "catch_warnings" would be to put it in a section of its own, "How To Test Your Code Which Uses Warnings", not as a footnote in "Available Classes". (Also, as a minor note to be taken at your discretion: should catch_warnings be named PEP 8 style as a class, since it is one? I don't really want to open that can of worms after reading the interminable threading.Event thread, but it seemed worth saying as long as was talking about this...) |
|||
msg72562 - (view) | Author: Brett Cannon (brett.cannon) * ![]() |
Date: 2008-09-05 03:39 | |
On Thu, Sep 4, 2008 at 4:18 PM, Glyph Lefkowitz <report@bugs.python.org> wrote: > > Glyph Lefkowitz <glyph@divmod.com> added the comment: > > The use of the term "filter" is pretty confusing. I would normally say > it was just me, but a bunch of other Twisted hackers seemed to interpret > it the same way: a "filter" is something that has an opportunity to > remove something else. For example, the python builtin function > "filter". Experimentation with the filters list seems to confirm this > impression, since later filters do not have an opportunity to access the > warnings that earlier filters have removed. The intuitive leap there is > to assume that inserting a filter at the head of the list won't do > anything different than inserting it at the tail, since a later filter > will remove it. > OK, so you were thinking of the filter list in a functional sense where exceptions are passed down the chain to each filter rule instead of a bunch of tests that stop checking once one of the rules applies. > I can't think of an obvious recommendation to improve the text for the > filter system itself, because upon reading it in more depth, it's fairly > clear. Maybe the heading could be changed to something more like > "intercepting warnings" or "controlling the way that warnings are > emitted"? Something attention-grabbing that describes its purpose and > doesn't use the word "filter". Even a sub-heading which simply > described how to use 'always' filter to cause every warning to be > emitted would be helpful. > OK. > The biggest improvement to the documentation for "catch_warnings" would > be to put it in a section of its own, "How To Test Your Code Which Uses > Warnings", not as a footnote in "Available Classes". > Fair enough. > (Also, as a minor note to be taken at your discretion: should > catch_warnings be named PEP 8 style as a class, since it is one? I > don't really want to open that can of worms after reading the > interminable threading.Event thread, but it seemed worth saying as long > as was talking about this...) It's partially historical since test.test_support.catch_warning() is a context manager created from a generator. But it's also because I want to have the option to change the context manager in the future if the bootstrapping reasons that led to it being a class can go away. I should probably change the section title to "Available Context Managers" so people don't start making assumptions. -Brett |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:38 | admin | set | nosy:
+ barry github: 48030 |
2008-09-05 03:39:46 | brett.cannon | set | messages: + msg72562 |
2008-09-04 23:18:00 | glyph | set | messages: + msg72553 |
2008-09-04 22:58:22 | brett.cannon | set | messages: + msg72548 |
2008-09-04 22:49:31 | glyph | set | resolution: not a bug |
2008-09-04 22:48:08 | glyph | set | status: open -> closed nosy: + glyph messages: + msg72541 |
2008-09-04 22:47:07 | exarkun | set | messages: + msg72540 |
2008-09-04 22:36:43 | brett.cannon | set | nosy:
+ brett.cannon messages: + msg72536 |
2008-09-04 22:13:48 | gvanrossum | set | priority: release blocker |
2008-09-04 22:08:29 | benjamin.peterson | set | nosy:
+ benjamin.peterson messages: + msg72532 |
2008-09-04 21:59:46 | exarkun | create |