[issue3780] No way to write unit tests for warnings

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Thu, Sep 4, 2008 at 4:18 PM, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote: > > Glyph Lefkowitz <[EMAIL PROTECTED]> added the comment: > > The use of the term "filter" is pretty confusing. I would normally say > it was just me, but a bunch of ot

[issue3780] No way to write unit tests for warnings

Glyph Lefkowitz <[EMAIL PROTECTED]> 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 e

[issue3780] No way to write unit tests for warnings

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Thu, Sep 4, 2008 at 3:48 PM, Glyph Lefkowitz <[EMAIL PROTECTED]> wrote: > > Glyph Lefkowitz <[EMAIL PROTECTED]> added the comment: > > Looks like we just misunderstood the way the warnings filter works, and > catch_warnings' interaction with

[issue3780] No way to write unit tests for warnings

Changes by Glyph Lefkowitz <[EMAIL PROTECTED]>: -- resolution: -> invalid ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3780] No way to write unit tests for warnings

Glyph Lefkowitz <[EMAIL PROTECTED]> 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! -- nosy: +glyph status: open -> closed ___

[issue3780] No way to write unit tests for warnings

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: 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. ___

[issue3780] No way to write unit tests for warnings

Brett Cannon <[EMAIL PROTECTED]> added the comment: 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

[issue3780] No way to write unit tests for warnings

Changes by Guido van Rossum <[EMAIL PROTECTED]>: -- priority: -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-

[issue3780] No way to write unit tests for warnings

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Would the new catch_warnings [1] context manager help in this regard? [1] http://docs.python.org/dev/library/warnings.html#warnings.catch_warnings -- nosy: +benjamin.peterson ___ Python tracker

[issue3780] No way to write unit tests for warnings

New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: 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-