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.

Author ncoghlan
Recipients barry, benjamin.peterson, brett.cannon, exarkun, ncoghlan, pitrou
Date 2008-09-09.10:38:02
SpamBayes Score 8.74388e-09
Marked as misclassified No
Message-id <1220956690.22.0.626835845341.issue3781@psf.upfronthosting.co.za>
In-reply-to
Content
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 warning was issued:
w.message (and all of the other warning attributes) were None. If the
implementation of WarningsRecorder hadn't been changed then this bug
would have never arisen.

The attributes of the last warning are cached on the recorder because by
*far* the most common intended use case that makes use of the warnings
recorder is to test operations that are expected to raise a single
warning. The list of warnings is retained solely for special cases where
one operation raises multiple warnings (e.g. see the py3k warnings tests
for __hash__ inheritance).

*aside from the use of @contextmanager, obviously
History
Date User Action Args
2008-09-09 10:38:10ncoghlansetrecipients: + ncoghlan, barry, brett.cannon, exarkun, pitrou, benjamin.peterson
2008-09-09 10:38:10ncoghlansetmessageid: <1220956690.22.0.626835845341.issue3781@psf.upfronthosting.co.za>
2008-09-09 10:38:04ncoghlanlinkissue3781 messages
2008-09-09 10:38:02ncoghlancreate