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 warn_explicit). > >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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4