[Python-Dev] [Python-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_exceptions.py Lib/test/test_hmac.py Lib/test/test_import.py Lib/test/test_macostools.py Lib/test/test_pep352.py Lib/test/test_py3kwarn.py Lib/test/test_random.py Lib/test/test_re.py Lib/test/test_struct.py Lib/test/test_structmembers.py Lib/test/test_sundry.py Lib/test/test_support.py Lib/test/test_symtable.py Lib/test/test_urllib.py Lib/test/test_urllibnet.py Lib/test/test_userstring.py Lib/test/test_warnings.py Lib/warnings.py Misc/NEWS

[Nick Coghlan]

Barry Warsaw wrote:
> On Sep 9, 2008, at 6:31 AM, Nick Coghlan wrote:
> 
>> It's also a bug that was introduced by the late API changes made to
>> WarningsRecorder in r66135 (when WarningsRecorder was moved from
>> test.test_support to warnings to make it officially supported for use
>> outside the Python test suite, the API was also changed).
> 
>> Instead of changing the API *again* could we please get the API reverted
>> back to the way it was for the two months prior to r66135 and only
>> change the location from test_support to warnings? (obviously, the use
>> of @contextmanager should still be removed since we don't particularly
>> want warnings to depend on contextlib).
> 
> As I commented in the bug, if this function is added to warnings I think
> it will be increasingly used as a way for code to suppress warnings.  If
> that's the behavior we want to allow, then I think making every warning
> but the last inaccessible is a bug.
> 
> If that's not a behavior we want to encourage then naming this function
> 'catch_warnings' and putting it in the warnings module sends the wrong
> message.  Better to stick it in unittest if test_support is
> unacceptable.  Or at least name it something that doesn't scream "use me
> in a way I don't intend!".

The last version of test_support.catch_warnings() actually did make all
warnings caught available via the w.warnings attribute. The API and
implementation changes in the move from test_support to the warnings
module didn't actually add any new features - they just changed the
w.warnings[idx] spelling to w[idx], moved from caching an explicit list
of attributes on the WarningRecorder to a __getattr__ based lookup on
the last warning and from a generator-based context manager to a custom
class with __enter__ and __exit__ methods. The last was actually a good
idea due to interpreter startup implications, but the first two changes
were unnecessary (and the attribute handling change is  actually what
led to issue3781).

Regardless, my preference at this point is for us to revert back to only
providing this feature through the regression test suite, since that
implementation at least worked properly, and reconsider the matter of
proving a more public version through the warnings module for 2.7/3.1.

Yes, it will make life a little more difficult for the twisted folks if
they can't rely on our test support module being present for whatever
reason, but they do have the option of including their own version of
catch_warnings() as a fallback if the regression test suite can't be found.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
            http://www.boredomandlaziness.org