[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Roundup Robot added the comment: New changeset 62033490ca0f by Nick Coghlan in branch 'default': Close #15486: Simplify the mechanism used to remove importlib frames from tracebacks when they just introduce irrelevant noise http://hg.python.org/cpython/rev/62033490ca0f -- nosy: +python-

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Atsuo Ishimoto : -- nosy: +ishimoto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Eric Snow added the comment: patch LGTM. Nice and clean. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Georg Brandl added the comment: Looks good and simplifies things. Green light :) -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Nick Coghlan : Removed file: http://bugs.python.org/file26573/issue15486_simplify_importlib_frame_removal.diff ___ Python tracker ___

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Nick Coghlan added the comment: Looking at the actual code - I don't think it actually makes sense to strip the frames in this case. Unlike the previous examples, it only comes up if someone is doing something deliberately pathological, at which point a little noise in the traceback is the lea

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Nick Coghlan added the comment: OK, after a bit of experimentation, it appears both 3.2 and 3.3 eventually get annoyed if you mess about too much with __pycache__. 1. They're both fine if __pycache__ is entirely unwritable (they just silently skip caching the bytecode) 2. 3.2 throws EOFError

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Nick Coghlan added the comment: The "release blocker" status comes from the test case I added in order to demonstrate the ability to strip a new frame sequence without needing to modify the C code. Currently that test (failing to write the PYC file) fails with an IsADirectory traceback that i

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Antoine Pitrou added the comment: That said, given the nature of the patch (a cleanup without any functional impact), I don't think it should be a release blocker. -- ___ Python tracker ___

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Antoine Pitrou added the comment: This is an elegant solution, +1 from me. -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-lis

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Chris Jerdonek added the comment: The test cases uploaded to issue 7559 ("TestLoader.loadTestsFromName swallows import errors") a while back contain a number of distinct cases (four, I think) in which an import error can be raised. IIRC, these include a couple recursive scenarios (cyclical im

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue15486] Standardised mechanism for stripping importlib frames from tracebacks

Nick Coghlan added the comment: In trying to find a new case that wasn't already covered by the test suite, I found an error which I'm not even sure should be an error. Doesn't 3.2 suppress failures that occur when attempting to implicitly cache the .pyc? Anyway, given the rest of the patch, t