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