On Wed, Jul 7, 2010 at 9:16 AM, Marius Gedminas <marius@gedmin.as> wrote:
On Wed, Jul 07, 2010 at 02:43:14PM +0200, Hanno Schlichting wrote:
On Wed, Jul 7, 2010 at 12:55 PM, Jim Fulton <jim@zope.com> wrote:
I'm not sure what the best way to handle this is. My initial thought is that all test runners should enable deprecations by default. This seems hard to enforce.
What about letting the testrunner (zope.testing / zope.testrunner) enable deprecation warnings by default, but add a command line switch to disable them or use the Python default?
+1
Although tests that check for functions emitting DeprecationWarnings should not rely on this; they should explicitly ensure DeprecationWarnings are not filtered away in their own setup.
AFAICT, there's no documented way of doing this.
Individual test modules can do this, but I'm uncomfortable having a test script make a global setting like this and the warning module doesn't seem to provide a way to capture the current state so it can be reset after running tests.
There's the warnings.catch_warnings context manager (since Python 2.6): http://docs.python.org/library/warnings.html#testing-warnings
This doesn't work if warnings are disabled. It can't enable them. It would be nice if passing record=True enabled all warnings, but it doesn't.
I'm sure it can be backported to older Python versions, or the test setUp/tearDown can fiddle with warnings.filters[:] directly.
Do you have any reason to believe that filters is a part of the warning module's public interface and not subject to change? It's not documented and not in __all__. I'm more inclined to create a test utility that temporarily replaces warnings.warn. Jim -- Jim Fulton