Python 2.7 disables deprecation warnings by default
I'm guessing that this has already been noticed and discussed, but Python 2.7 disables deprecation warnings by default. This will cause many tests to fail that checked that deprecation were issued. This change seems likely to make Python's deprecation system useless and thus unused. I noticed this yesterday when testing a project with Python 2.7 that had some deprecation tests. I modified the test runner script to call: warnings.simplefilter('default') to renable deprecation warnings. This allowed my tests to pass and also, ironically, showed new useful deprecation warnings in asyncore. 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. 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. Jim -- Jim Fulton
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.
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.
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? The test.py script from Zope 2 used to have a --nowarn option to disable all warnings. I think developers should always care about deprecation warnings and it's only developers who will run tests. I can understand why normal users of a Python program shouldn't see deprecation warnings - they usually cannot do anything about them. I also heard many reports from people asking questions about those deprecation warnings in a Plone context. Normal users don't know the difference between a deprecation warning and a SyntaxError or any other warning for that matter. All they see is a "warning" and get anxious. Hanno
On Wed, Jul 7, 2010 at 8:43 AM, Hanno Schlichting <hanno@hannosch.eu> 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.
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.
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?
As I said, I think it makes the most sense for the testrunner to enable deprecation warnings, but it will be hard to get all test runners to do this. Keep in mind that our packages may be run with other test runners, most notably, but not exclusively the setup test runner.
The test.py script from Zope 2 used to have a --nowarn option to disable all warnings.
A flag to disable warnings will cause test failures is tests that deprercation warnings are issued. I guess such tests need to be changed to use some sort of warning mock so they don't depend on the unpredictable state of warnings. The warnings module is such a mess. If it weren't in the standard library, I might be tempted to help try to help fix it. :) Jim -- Jim Fulton
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.
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 I'm sure it can be backported to older Python versions, or the test setUp/tearDown can fiddle with warnings.filters[:] directly. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
I'm guessing that this has already been noticed and discussed, but Python 2.7 disables deprecation warnings by default.
This will cause many tests to fail that checked that deprecation were issued.
This change seems likely to make Python's deprecation system useless and thus unused.
I noticed this yesterday when testing a project with Python 2.7 that had some deprecation tests. I modified the test runner script to call:
warnings.simplefilter('default')
to renable deprecation warnings. This allowed my tests to pass and also, ironically, showed new useful deprecation warnings in asyncore.
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.
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.
As of Python 2.6, the warnings module sports a context manager:: with warnings.catch_warnings(): warnings.simplefilter("default") fxn() Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkw0iDUACgkQ+gerLs4ltQ4C7gCfd8WbirfwtAxnc99yhjfdPlvK 4SYAoNxDTkSp1TAdOe2Go3sBJtM0b1/t =3cc2 -----END PGP SIGNATURE-----
On Wed, Jul 7, 2010 at 9:59 AM, Tres Seaver <tseaver@palladion.com> wrote:
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.
As of Python 2.6, the warnings module sports a context manager::
with warnings.catch_warnings(): warnings.simplefilter("default") fxn()
Ah, this works because catch_warnings saves and later restores the filter configuration. Cool. Jim -- Jim Fulton
participants (4)
-
Hanno Schlichting -
Jim Fulton -
Marius Gedminas -
Tres Seaver