[Python-Dev] Py3k DeprecationWarning in stdlib (original) (raw)
Jean-Paul Calderone exarkun at divmod.com
Thu Jun 26 17:28:01 CEST 2008
- Previous message: [Python-Dev] Py3k DeprecationWarning in stdlib
- Next message: [Python-Dev] Py3k DeprecationWarning in stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 27 Jun 2008 01:14:36 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
Jean-Paul Calderone wrote: [snip]
The real problem with testing many uses of the warning system is that it doesn't expose enough public APIs for this to be possible. You have to use APIs which are, apparently, private (such as warnexplicit). Hmm, I think the bigger problem is that there is no documented way to save the warnings filter and restore it to a previous state - the 'filters' attribute (which holds the actual list of filters) isn't documented and isn't included in all. This makes it hard to write an officially supported test that fiddles with the warning settings then puts them back the way they were.
It sounds like you're agreeing that there aren't enough public APIs. Making warn_explicit public addresses this particular problem in one way - by letting applications hook into the warning system before filters are applied. Making the filter list public is another way, since it would let applications clear and then restore the filters.
I don't particularly care about the details, I just want some public API for this. Making warn_explicit public seems better to me, since it was already there in previous versions of Python, and it lets you completely ignore both the filters list and the global registry, but if others would rather make the filters and global registry a part of the public API, that's fine by me as well.
Jean-Paul
- Previous message: [Python-Dev] Py3k DeprecationWarning in stdlib
- Next message: [Python-Dev] Py3k DeprecationWarning in stdlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]