> 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