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
Suboptimal stacklevel of deprecation warnings for formatter and imp modules #67998
Comments
https://hg.python.org/cpython/rev/2a336cc29282 changed stacklevel of some deprecation warnings. $ cat test.py
import formatter
import imp
$ python3.4 -Wd test.py
/usr/lib64/python3.4/formatter.py:24: PendingDeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
'Python 3.6', PendingDeprecationWarning)
/usr/lib64/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
PendingDeprecationWarning)
$ python3.5 -Wd test.py
_frozen_importlib:321: DeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
/usr/lib64/python3.5/importlib/_bootstrap.py:321: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
return f(*args, **kwds) |
Probably need to introduce a new keyword argument just for deprecated imports or some helper function in importlib to get the stack depth right (else there is a risk of breaking the stack depth in any minor release whenever importlib's depth shifts). Something like the following should be enough (obviously done in warnings instead of per-file): try: Otherwise the depths should just go back to what they were at. |
Similar feature is needed for warnings in the re module. Methods of regular expression pattern can be called directly or from module-level wrappers. In these case the stack level differs by 1. And sometimes warnings are emitted in recursive parser, when stack level is variable. |
Here is a private function in warnings for calculating the stack depth to the first frame not referencing some key string. Can someone look at it to make sure it looks reasonable? I'm starting with it being private since it uses sys._getframe() and I don't know how widely needed it is. |
Unfortunately this will not help for re, because the trace passes through three files: Lib/sre_parse.py, Lib/sre_compile.py and Lib/re.py. |
OK, I'll look at making it more general for multiple names to skip. |
bpo-24305 covers either making this a public API for general use, or else just making module level deprecation warnings skip the import machinery automatically. I also wonder whether Eric's _boostrap_external changes might have broken any of the frame hiding tricks for tracebacks. |
I had a similar concern, Nick, but don't think I did anything that would have broken the frame hiding logic. That said, I did not take stacklevel for warnings into account. |
Latest patch should work for Serhiy's needs by taking a container of names to compare against the filename instead of a single argument. |
This regression isn't thrilling, but it's not the kind of "OMG we can't release with this bug" level of escalation I associate with an actual release blocker. Let's at least defer it for now, and maybe we'll even reduce it further later. |
Merging with the other issue so there is a single place to track this |
…o the user. Generating deprecation warnings with the correct stacklevel is tricky to get right. Up to now, users have not been seeing these deprecation warnigns because they had incorrect stacklevels. See python/cpython#68493 and python/cpython#67998 for good discussions, as well as ipython/ipython#8478 (comment) and ipython/ipython#8480 (comment) for more context. We see these issues directly. Normally stacklevel=2 might be enough to target the caller of a function. However, in our deprecation warning in the __init__ method, each level of subclasses adds one stack frame, so depending on the subclass, the appropriate stacklevel is different. Thus this PR implements a trick from a discussion in Python to calculate the first stack frame that is external to the ipywidgets library, and use that as the target stack frame for the deprecation warning.
…o the user. Generating deprecation warnings with the correct stacklevel is tricky to get right. Up to now, users have not been seeing these deprecation warnigns because they had incorrect stacklevels. See python/cpython#68493 and python/cpython#67998 for good discussions, as well as ipython/ipython#8478 (comment) and ipython/ipython#8480 (comment) for more context. We see these issues directly. Normally stacklevel=2 might be enough to target the caller of a function. However, in our deprecation warning in the __init__ method, each level of subclasses adds one stack frame, so depending on the subclass, the appropriate stacklevel is different. Thus this PR implements a trick from a discussion in Python to calculate the first stack frame that is external to the ipywidgets library, and use that as the target stack frame for the deprecation warning.
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: