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@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org