New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
warnings.simplefilter("always") does not make warnings always show up #48430
Comments
If a warning is emitted then a filter with the "always" rule is added exarkun@charm:~$ python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> def f():
... warnings.warn("foo")
...
>>> f()
/home/exarkun/.pythonstartup.py:2: UserWarning: foo
>>> warnings.simplefilter("always")
>>> f()
>>> The "always" filter is documented as "always print matching warnings" |
If you didn't raise the warning before using the simple filter, this |
Obviously the big problem with that change, Benjamin, is you will be |
Oh, do we not consider __warningsregistry__ an implementation detail? |
On Wed, Oct 22, 2008 at 3:39 PM, Benjamin Peterson
I guess you could view it that way. I just know I find it extremely If we made __warningsregistry__ about just recording what warnings |
A simple solution would be to allow warn_explicit to be overridden. Then |
On Wed, Oct 22, 2008 at 4:11 PM, Benjamin Peterson
You say "simple" from a comprehension standpoint, I say "pain" in |
Don't worry, Brett; you made it really easy. :) Here's a patch. |
So how about it? |
I am still on sabbatical so no code review from me. But from the standpoint of making warn_explicit be overloadable, I'm on |
+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. |
It sounds like it would be cleaner to apply Brett's idea in msg75122, rather than have the user override (and alternate implementations implement) another obscure hook. We have enough hooks that nobody knows about, IMHO. |
The attached patch fixes the OP's use case on the Python side by re-ordering the tests, such that "always" prevents the short-circuit from firing:: $ ./python
Python 2.6.5+ (release26-maint, Apr 29 2010, 21:24:12)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings as o_warnings
>>> import sys
>>> sys.modules['_warnings'] = 0
>>> del sys.modules['warnings']
>>> import warnings as py_warnings
>>> def f():
... py_warnings.warn('foo')
...
>>> f()
__main__:2: UserWarning: foo
>>> f()
>>> py_warnings.simplefilter('always')
>>> f()
__main__:2: UserWarning: foo
>>> f()
__main__:2: UserWarning: foo |
This patch tidies up the FilterWarnings tests to nomalize use of 'self.assertEquals' (matching the rest of the module) and make the 'test_always' assertions meaningful. |
This patch adds tests for the 'error', 'ignore', and 'always' filters being applied *after* the default warning has been issued, and therefore the registry populated. It causes failures for the 'error' and 'always' on both the Python and C sides. |
This patch replaces my earlier 'py_warnings' patch. It revamps the Python side to check filters before deciding not to emit the warning based on the registry. The new "<filter>_after_default" tests pass on the Python side with this patch. |
Here is a patch implementing an alternate approach, with a version number added in the registry dicts. It also reuses Tres' test cases. Removing 2.7 because at this point we probably don't want to add non-minimal changes there (outside of the ssl module, that is :-)). |
Brett, do you want to review this? |
New changeset 8adb2c6e0803 by Antoine Pitrou in branch '3.4': New changeset 4bc60eb68d3e by Antoine Pitrou in branch 'default': |
Ok, this is pushed to 3.x. |
I believe this fix causes this bug: http://bugs.python.org/issue29672 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: