Re: [Python-Dev] 'warnings' module changes still breaking Twisted, still looking for a fix
On 10:18 pm, musiccomposition@gmail.com wrote:
That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored.
Thanks for the pointer - this is interesting. I misunderstood the way the warnings filter worked. It looks like this combination of features may in fact be all we need. It would be nice if application code could otherwise "officially" keep track of the warnings filter (my understanding is that 'filters', despite the public-looking name, is private, since it is absent from the documentation?) but that doesn't sound like a release blocker.
On Thu, Sep 4, 2008 at 3:39 PM,
On 10:18 pm, musiccomposition@gmail.com wrote:
That's why catch_warning keeps track of the warnings filter too, so you can call warnings.simplefilter("always") within the context manager and the filter state will be restored.
Thanks for the pointer - this is interesting. I misunderstood the way the warnings filter worked. It looks like this combination of features may in fact be all we need. It would be nice if application code could otherwise "officially" keep track of the warnings filter (my understanding is that 'filters', despite the public-looking name, is private, since it is absent from the documentation?) but that doesn't sound like a release blocker.
If you are after an API to return an opaque object that represents the filter and be able to use that opaque object to reset the filter at a later point (along with a matching reset function), then create an issue for 2.7/3.1 and assign it to me as I was thinking about doing that myself and would love to get Twisted's input on it. _Brett
participants (2)
-
Brett Cannon -
glyph＠divmod.com