Message100525
| 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:43 | mark.dickinson | set | recipients:
+ mark.dickinson, brett.cannon, exarkun, benjamin.peterson |
| 2010年03月06日 11:17:43 | mark.dickinson | set | messageid: <1267874263.31.0.905683860848.issue4180@psf.upfronthosting.co.za> |
| 2010年03月06日 11:17:41 | mark.dickinson | link | issue4180 messages |
| 2010年03月06日 11:17:40 | mark.dickinson | create |
|