[Python-Dev] Py3k DeprecationWarning in stdlib

[Jean-Paul Calderone]

On Tue, 24 Jun 2008 23:03:33 -0000, glyph at divmod.com wrote:
>On 10:05 pm, ncoghlan at gmail.com wrote:
>>We need to be especially careful with the unit test suite itself - changing 
>>the test code to avoid the warning will normally be the right answer, but 
>>when the code is actually setting out to test the deprecated feature we 
>>need to suppress the warning in the test suite instead.
>
>This is a dangerous road to go down.  If you suppress warnings in the test 
>suite, you might suppress additional warnings which should actually be 
>reported.  Or, if the API gets modified in some way that the warning is 
>supposed to be emitted but isn't any longer, it will be silent.  It's easy 
>to accidentally suppress too much or not enough.
>
>The way we've dealt with this in Twisted is adding an 'assertWarns' method 
>so that we can invoke an API that is supposed to generate a warning, and (A) 
>that warning and only that *specific* warning will not be emitted, and (B) 
>if the API stops emitting the warning in the future, the test will fail and 
>we will notice.
>
>It's also nice to have this facility in the test harness itself, so that you 
>don't run the additional risk of accidentally (and silently) leaving warning 
>suppression in place for subsequent tests.

It would be *extra* nice to have this facility added to the standard
library, since assertWarns in Twisted is broken by changes in Python
2.6 (ie, our tests for warnings all fail with trunk at HEAD).  For now,
we will probably address this by switching to a different warning
API.  In the long term, it'd be better for us, other Python developers,
and the standard library if there were an API in the standard library
which facilitated testing of warnings.

Jean-Paul