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 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 ---------- nosy: +ncoghlan resolution: accepted -> status: closed -> open _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3781> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
