[issue7849] Improve "test_support.check_warnings()"

Ezio Melotti added the comment: 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. -- ___ Python tracker

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: Done on trunk with r78758 and r79049. -- resolution: accepted -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: Patch updated. -- assignee: -> flox resolution: -> accepted versions: +Python 3.2 Added file: http://bugs.python.org/file16471/issue7849_check_warnings_v3.diff ___ Python tracker

[issue7849] Improve "test_support.check_warnings()"

Changes by Florent Xicluna : Removed file: http://bugs.python.org/file16120/issue7849_check_warnings_v2.diff ___ Python tracker ___ ___ Python-

[issue7849] Improve "test_support.check_warnings()"

Mark Dickinson added the comment: 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. -- nosy: +mark.dickinson ___ Python tracker

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: > Antoine Pitrou 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 che

[issue7849] Improve "test_support.check_warnings()"

Antoine Pitrou added the comment: "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

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: Fixed. Tested with different options: "-Wd", "-3" -- Added file: http://bugs.python.org/file16120/issue7849_check_warnings_v2.diff ___ Python tracker _

[issue7849] Improve "test_support.check_warnings()"

Changes by Florent Xicluna : Removed file: http://bugs.python.org/file16118/issue7849_check_warnings.diff ___ Python tracker ___ ___ Python-bug

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: 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. --

[issue7849] Improve "test_support.check_warnings()"

Brett Cannon added the comment: 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 not

[issue7849] Improve "test_support.check_warnings()"

Florent Xicluna added the comment: Patch for the context managers. Patch to fix the stdlib. -- Added file: http://bugs.python.org/file16119/issue7849_lib_fixes.diff ___ Python tracker __

[issue7849] Improve "test_support.check_warnings()"

Changes by Florent Xicluna : -- keywords: +patch Added file: http://bugs.python.org/file16118/issue7849_check_warnings.diff ___ Python tracker ___

[issue7849] Improve "test_support.check_warnings()"

New submission from Florent Xicluna : 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