Repository navigation
Warnings stacklevel frames to skip #69403
Description
| BPO | 25216 |
|---|---|
| Nosy | @JimJJewett, @jayvdb |
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:
assignee = None
closed_at = None
created_at = <Date 2015-09-22.15:47:00.527>
labels = ['type-feature', 'library']
title = 'Warnings stacklevel frames to skip'
updated_at = <Date 2015-12-10.08:16:01.708>
user = 'https://github.com/JimJJewett'bugs.python.org fields:
activity = <Date 2015-12-10.08:16:01.708>
actor = 'jayvdb'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2015-09-22.15:47:00.527>
creator = 'Jim.Jewett'
dependencies = []
files = []
hgrepos = []
issue_num = 25216
keywords = []
message_count = 2.0
messages = ['251328', '256169']
nosy_count = 2.0
nosy_names = ['Jim.Jewett', 'jayvdb']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue25216'
versions = ['Python 3.6']
Activity
jimjjewett commentedon Sep 22, 2015
warnings.warn(stacklevel=2) is a longstanding idiom.
It broke in 3.3 because python itself added some additional infrastructure frames in between; now stacklevel should be 8 or 10 in some releases.
bpo-24305 adds a workaround for 3.5, to ignore internal frames -- defined as those which contain both 'importlib' and '_bootstrap' in filename.
I would prefer to see a supported hook, so that either the caller or the program setup could list other modules or packages to ignore when counting frames. That way, I could write
and otherlib could ensure that the warning pointed to mycall, rather than to something internal to otherlib, even if otherlib were refactored to a different stack depth.
Ignoring just the import machinery would of course be a good default.
jayvdb commentedon Dec 10, 2015
This looks a lot like the patch on http://bugs.python.org/issue850482 aka #39615
gpshead commentedon Jan 1, 2023
duplicate of #39615