homepage

Currently this context manager is used in 3 different situations:
 - to silence standard warnings
 - to record warnings in a list, in order to verify them
 - to silence py3k warnings
But it does not accept any parameter, and it does not *check* if the filter is obsolete. It silence *all* warnings, blindly.
I would like to propose an enhancement of this function, which accepts a list of filters as parameters, and which verifies that there's really something to catch.
An optional boolean argument "lazy" can be used to disable the check.
 check_warnings([filter[, ...[, lazy=False]]])
Additionnally, a sister function will filter only the py3k warnings:
 check_py3k_warnings([filter[, ...[, lazy=False]]])
See the patch and its docstring for details.
Note: this context manager could be used to fix the last part of #7092 

Patch for the context managers.
Patch to fix the stdlib.

In other words you want a way to limit what the context manager catches and records while allowing all other warnings to propagate. That seems fine.
I didn't do much of a code review, but there is a grammatical error in the docstring: change "a filter catch nothing" to "a filter catches nothing".

Actually this patch enhances check_warnings() in other ways too:
 - it verifies if the warning is effectively raised
 - it deals with "py3k" warnings separately
It could be used instead of warnings.filterwarnings() with some benefits.

Fixed. Tested with different options: "-Wd", "-3"

"lazy" sounds like a bad name for that parameter. It makes me think of lazy evaluation, not error checking.
There's also the problem that check_py3k_warnings() will check all DeprecationWarnings, not only py3k-specific ones. We need a Py3kDeprecationWarning subclass.
Besides, there doesn't seem to be any point accepting positional arguments in check_py3k_warnings(). If you want a custom filter, just use check_warnings() instead.

+1 on Py3kDeprecationWarning.

> Antoine Pitrou <pitrou@free.fr> added the comment:
>
> "lazy" sounds like a bad name for that parameter. It makes me think of lazy evaluation, not error checking.
>
"check_warnings(quiet=True)" sounds good?
> There's also the problem that check_py3k_warnings() will check all DeprecationWarnings, not only py3k-specific ones. We need a Py3kDeprecationWarning subclass.
+0 about this additional subclass, because the current py3k warnings
are around since 2.6 (r55525).
And if the subclass is accepted, we will need Py3kSyntaxWarning too.
Maybe the "-3" warnings should become "-Wd" warnings at some point,
because 3.2 will probably become trunk after
"branches/release27-maint/" is created. Then we will deprecate the
"-3" switch :)
> Besides, there doesn't seem to be any point accepting positional arguments in check_py3k_warnings(). If you want a custom filter, just use check_warnings() instead.
>
Both are needed, because the "check_py3k_warnings" is no-op except if
"-3" is passed on the command line.
I thought to implement "check_warnings(py3k=True)", at first. But
since this function will be used in 83% of the cases, it may be more
convenient to use a specific name "check_py3k_warnings":
 - 56 test modules will use check_py3k_warnings
 - 11 test modules will use check_warnings

This is somewhat orthogonal, but it might also be nice to have some way to tell check_warnings not to touch __warningregistry__. See also issue 4180.

Patch updated.

Done on trunk with r78758 and r79049.

I backported this to 2.6 in r83537 in order to fix #7092. I used a leading underscore on _check_py3k_warnings to make it private because no new features should be added to 2.6.