Florent Xicluna <florent.xicl...@gmail.com> added the comment: > Antoine Pitrou <pit...@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 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7849> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
