Brett Cannon <[EMAIL PROTECTED]> added the comment: On Wed, Aug 20, 2008 at 2:53 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > > Benjamin Peterson <[EMAIL PROTECTED]> added the comment: > > On Wed, Aug 20, 2008 at 4:51 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> Brett Cannon <[EMAIL PROTECTED]> added the comment: >> >> On Wed, Aug 20, 2008 at 10:29 AM, Benjamin Peterson >> <[EMAIL PROTECTED]> wrote: >>> >>> Benjamin Peterson <[EMAIL PROTECTED]> added the comment: >>> >>> I don't think the using argument should live in warnings; it's too test >>> specific. I recommend we still keep a catch_warning in test_support (or >>> even just test_warnings since this seems to be the only use-case). >>> >> >> But decoupling from the core code of the context manager for this is >> not straight-forward without mucking around in sys.modules and that is >> always a risky thing to do. > > Why would you have to much around in sys.modules? >>
Well, the bulk of the code needs to live in 'warnings' for it to exist if the 'test' package is missing. So any differences need to come from the test.support version. Now the module argument is so that you can control exactly what module has its showwarnings() implementation changed without worrying about what 'warnings' is set in sys.modules and really mucking up the interpreter. But if this argument is missing then warnings.catchwarnings() will have to set warnings.showwarnings() blindly since it doesn't know what module object is being tested. So if I want that change to happen on another module, I need to change what module is in sys.modules, call the context manager, and then put it all back so that what I want happen occurs. That's why you would have to mess with sys.modules. =) The argument could be renamed '_using', but that just seems silly. And with it being considered keyword-only (and I will make it the last argument listed, then most people won't ever run into it. _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3602> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
