[Zope-dev] Python 2.7 disables deprecation warnings by default

Jim Fulton jim at zope.com
Wed Jul 7 09:33:34 EDT 2010


On Wed, Jul 7, 2010 at 9:16 AM, Marius Gedminas <marius at 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 at 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


More information about the Zope-Dev mailing list