This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients brett.cannon, eric.snow, ncoghlan, njs, takluyver
Date 2015-05-28.00:38:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432773526.55.0.606860913383.issue24305@psf.upfronthosting.co.za>
In-reply-to
Content
Somewhat related issues are issue 16217 (traceback noise when running under python -m) and issue 23773 (traceback noise when running under custom import hooks)

For 3.4 and 3.5, we may want to consider a brute force solution where the warnings module just straight up ignores _frozen_importlib frames when counting stack levels.

For 3.6+, I've occasionally pondered various ideas for introducing the notion of a "frame debugging level". The most recent variant of that idea would be to have all frames live in level zero by default, but there'd be a way to flag a module at compile time to set it higher for the code objects created by that module.

Displaying those frames in tracebacks would then be tied to both the current frame's debugging level and the interpreter's verbosity level (whichever was higher), while other stack related operations (like the warnings stacklevel and frame retrieval) would only consider frames at the current frame's debugging level and below.
History
Date User Action Args
2015-05-28 00:38:46ncoghlansetrecipients: + ncoghlan, brett.cannon, njs, eric.snow, takluyver
2015-05-28 00:38:46ncoghlansetmessageid: <1432773526.55.0.606860913383.issue24305@psf.upfronthosting.co.za>
2015-05-28 00:38:46ncoghlanlinkissue24305 messages
2015-05-28 00:38:46ncoghlancreate