This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients benjamin.peterson, brett.cannon, exarkun, mark.dickinson
Date 2010-03-06.11:17:40
SpamBayes Score 1.4428218e-07
Marked as misclassified No
Message-id <1267874263.31.0.905683860848.issue4180@psf.upfronthosting.co.za>
In-reply-to
Content
+1 for Benjamin's patch, having just been bitten by this exact problem.

I'm trying to do unit testing, checking both that a piece of code produces a DeprecationWarning and that it gives the correct result, with something like:

    with warnings.catch_warnings():
        warnings.filterwarnings("ignore", category=DeprecationWarning)
        self.assertEqual(my_func(my_args), expected_result)

    with warnings.catch_warnings():
        warnings.filterwarnings("error", category=DeprecationWarning)
        self.assertRaises(DeprecationWarning, my_func, *my_args)

The first call still registers the warning, even though it's ignored, so the second assertRaises fails.  Benjamin's patch would seem to provide a way to fix this.

Perhaps I'm missing an obvious better way to do this.

N.B. The above is a too simple version of the real problem: it actually works as intended, for fragile reasons:  the "ignore"d warning is registered on __name__, while the "always"d warning ends up being registered on unittest.case, so there's no conflict.
History
Date User Action Args
2010-03-06 11:17:43mark.dickinsonsetrecipients: + mark.dickinson, brett.cannon, exarkun, benjamin.peterson
2010-03-06 11:17:43mark.dickinsonsetmessageid: <1267874263.31.0.905683860848.issue4180@psf.upfronthosting.co.za>
2010-03-06 11:17:41mark.dickinsonlinkissue4180 messages
2010-03-06 11:17:40mark.dickinsoncreate