[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Luke Kenneth Casson Leighton added the comment: erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below. simply put: if the freeze on dis

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Luke Kenneth Casson Leighton added the comment: NUTS. many apologies: my comments should have gone to issue 3871 not 3781. arse! is it possible to delete comments? :) -- ___ Python tracker _

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Ned Deily : -- Removed message: http://bugs.python.org/msg121089 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Ned Deily : -- Removed message: http://bugs.python.org/msg121090 ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: This example shows the behavior: from warnings import catch_warnings def test(): with catch_warnings(True) as w: assert str(w.message) == "foo", "%r != %r" % (w.message, "foo") test() This fails with

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> brett.cannon nosy: +brett.cannon ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Thu, Sep 4, 2008 at 3:10 PM, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > > New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>: > > This example shows the behavior: > >from warnings import catch_warnings > >def test(): >

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: The specific exception type isn't that important to me, as long as I can rely on it being something in particular. ___ Python tracker <[EMAIL PROTECTED]>

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: I won't be able to get to this until tonight, but assuming no one objects, I will make it be an AttributeError and a release blocker so that the API can be considered stable in rc1. -- priority: -> release blocker

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Why wouldn't w.message simply be None? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: There is no specific reason why it would be, although that is an option as well. Part of the problem with None is that it is a legitimate default value for some arguments to showwarning() so it doesn't necessarily reflect that no exception was r

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: The attached patch has WarningsRecorder raise AttributeError when there is no recorded attribute and yet one tries to access warnings attributes. And just so you know, JP, make sure to use keyword arguments when calling catch_warnings() (in cas

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: I hate to make API suggestions this late in the process, but this is the first time I've looked at this. I think the basic problem is that the context manager API is a bit weird. What I don't like is the fact that __getattr__() indexes the

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: And I forgot to mention that subclassing list is a new thing I tossed in when I moved the code and tweaked the API so that's another reason that using list's abilities was not pervasive. ___ Python tracker <[

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: Sounds good. This needs to go into 2.6 and 3.0. And while you're add it, can you add catch_warnings to the __all__? -- versions: +Python 3.0 ___ Python tracker <[EMAIL PROTECTED]>

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: The use of __getattr__ is a historical artifact. Originally there was no way to record multiple warnings as the object returned by catch_warnings() represented only a single instance of a warning. But then the ability to record multiple warnings

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Sat, Sep 6, 2008 at 11:31 AM, Barry A. Warsaw <[EMAIL PROTECTED]> wrote: > > Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: > > Sounds good. This needs to go into 2.6 and 3.0. Oh, definitely. > And while you're add > it, can you a

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Brett Cannon <[EMAIL PROTECTED]>: -- assignee: -> brett.cannon ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-li

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: The new patch ditches the WarningsRecorder class and just returns a list that is directly mutated. I also removed all uses of test.test_support.catch_warning() and moved them over. Docs have been thoroughly updated to give example usage. And las

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Brett Cannon <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11382/catch_warnings_atts.diff ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: The patch mostly looks good. However, all the w[-1] logic looks rather verbose to me since its main use case in testing will be making sure *one* warning happened. Returning a list adds the extra step of checking the length and then indexin

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Mon, Sep 8, 2008 at 3:12 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > The patch mostly looks good. However, all the w[-1] logic looks rather > verbose to me since its main u

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: Covered by r66321 in the trunk. Now I just need to merge into 3.0. ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: r66322 has the fix in 3.0. -- resolution: -> accepted status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Reopening this because I disagree with the fix - I would prefer to see catch_warnings() reverted back to the API and implementation* it used prior to the test_support->warnings migration. That version had perfectly clear semantics when no warni

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: As far as the use cases go, it was moved out of test.test_support to warnings SOLELY due to the requests from the twisted folks for assistance in testing their generation of warnings. The fact that it is also useful for suppressing warnings in g

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: With a name like catch_warnings() in the warnings module, it will definitely get used in production code to suppress warnings. If its intended to be used only by tests, then it belongs somewhere else. If not test_support then maybe unittest

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: It turns out the warnings.catch_warnings version has re-entrancy issues due to the fact that it can't use @contextmanager: Python 2.6b3+ (trunk:66143M, Sep 2 2008, 20:04:43) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I also have to comment on the "makes the API simpler to use" note in the checkin message. No, no it doesn't. See all those "warning[-1]" calls in the current unit tests? They're all unhelpful, because if a warning doesn't get raised, you're goin

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Nick Coghlan <[EMAIL PROTECTED]>: -- assignee: -> ncoghlan ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list m

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: Exposing a list seems like a great low-level API to me. There are no [-1]s in the Twisted codebase as a result of using this API because we have a higher-level API built on top of it. Having this low-level API that doesn't try to make a

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: test.test_support *is* a public API (it's even documented). ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Jean-Paul Calderone <[EMAIL PROTECTED]> added the comment: There was a discussion on python-dev about using things from the `test` package from code outside the `test` package: http://mail.python.org/pipermail/python-dev/2008-August/081860.html ___ Python tra

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: In working on the reversion patch, I just noticed that r66321 also incorrectly removed a whole pile of w.reset() calls. When using a single catch_warning() context to test two or more operations which may raise the same warning, you *must* call

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I will put together two patches: one that reverts all the way back to what we had in the betas, and another which just reverts the Python test suite changes in the most recent checkin (instead modifying test_support.catch_warning to use the modi

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Fully reverting the relocation also required reverting r66197 (a belated checkin of test_py3kwarn for the r66135 changes). There was also a change to test_warnings that had to be reverted (it appeared to have been mistakenly checked in as part

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Reversion patch attached - it does indeed recreate some nasty dependencies from the main areas of the standard library on to the regression test suite. That's enough to kill the idea of a complete reversion as far as I'm concerned - I'll get the

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: I can understand the amount of time it might take to revert this; merging was horrendous and stuff was partially combined into single patches as to get a review done for all related changes instead of doing more atomic commits if a review was no

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: No worries - the only reason I suggested full reversion at all is because I had temporarily forgotten why the relocation had become so necessary (i.e. we needed the feature ourselves in the main part of the standard library to avoid emitting spu

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: On Tue, Sep 9, 2008 at 3:13 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Nick Coghlan <[EMAIL PROTECTED]> added the comment: > > No worries - the only reason I suggested full reversion at all is > because I had temporarily forgotten why the r

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Not quite that basic for the warnings.catch_warnings() part. I plan to leave the current warnings.catch_warnings() alone (aside from adding some re-entrancy checks), and add back a test.test_support.check_warnings() that uses a WarningsRecorder

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Cleanup patch now attached. Details of changes: - warnings.catch_warnings() now has reentry guards (and associated tests) to prevent silent errors when misused - added back a test_support.check_warnings() convenience wrapper (deliberately chan

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Brett Cannon <[EMAIL PROTECTED]> added the comment: Code looks good. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing list

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Brett Cannon <[EMAIL PROTECTED]>: -- keywords: +patch -needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bug

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Applied to trunk for 2.6 in r66386. -- priority: release blocker -> deferred blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Blocked merge in the py3k branch since it requires some fiddling to handle the change from test.test_support to test.support. I'll post a new patch here for the py3k forward port when I can (I may not make it before 3.0b4 though, so unassigning

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Thu, Sep 11, 2008 at 9:03 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Nick Coghlan <[EMAIL PROTECTED]> added the comment: > > Blocked merge in the py3k branch since it requires some fiddling to > handle the change from test.test_supp

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: 3.0 version of the patch attached (it turned that it wasn't so much test_support itself that caused the forward port problems, as the fact that most of the tests that use this feature in 2.x are testing specifically for Py3k warnings, or for oth

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Nick Coghlan <[EMAIL PROTECTED]>: -- keywords: +needs review ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Nick Coghlan <[EMAIL PROTECTED]> added the comment: The 3.0 forward port of r66386 still needs a once over before being committed (there were enough differences that I don't think the review of the 2.6 version is enough to cover the 3.0 version as well). Once that is done, then this issue can be

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: release blocker -> deferred blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3781] warnings.catch_warnings fails gracelessly when recording warnings but no warnings are emitted

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Applied in r66945. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ _