On Wed, Jul 7, 2010 at 8:43 AM, Hanno Schlichting <ha...@hannosch.eu> wrote:
> On Wed, Jul 7, 2010 at 12:55 PM, Jim Fulton <j...@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
> 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. :)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -