[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Change by Brett Cannon : -- nosy: -brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Nick Coghlan added the comment: Regarding directories and zipfiles, runpy._run_module_as_main also handles those - the CLI effectively transforms directory and zipfile execution into a "python -m __main__" call with a suitably adjusted sys.path[0] entry (i.e. the given directory or zip archive

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Nick Coghlan added the comment: Aye, separating the two discussions is a good idea. I've filed https://bugs.python.org/issue31299 for the traceback RFE, and added it as a dependency here. -- dependencies: +Add "ignore_modules" option to TracebackException.format()

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Dmitry Kazakov added the comment: Since runpy also handles the execution of directories and zip files, I think it would be reasonable to clean up tracebacks in these cases, too. The ignore_modules argument would be a great addition to the traceback module. Should I create a separate issue/pull

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Nick Coghlan added the comment: The reason we don't always drop the importlib frames in general is because we need them when we're debugging importlib itself, as well as when folks are calling into it directly. However, I think it would be reasonable to do it unconditionally for unhandled exce

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Dmitry Kazakov added the comment: In order to load and compile the module code, runpy calls the loader's get_code method. Because that happens outside of the normal import process, and PyImport_ImportModuleLevelObject is currently the only place where remove_importlib_frames is being invoked,

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Nick Coghlan added the comment: Hmm, when I haven't moved an issue forward in over two years, I guess that's a fair sign I'm not *actually* working on it... -- assignee: ncoghlan -> ___ Python tracker ___

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

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

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Changes by Ezio Melotti : -- components: +Library (Lib) nosy: +ezio.melotti stage: -> needs patch ___ Python tracker ___ ___ Python-b

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Nick Coghlan added the comment: Agreed. We do have a mechanism in place to deal with this specifically for importlib in 3.3 (which is why the first traceback is cleaner, although it's not triggering in the SyntaxError case for some reason), but it makes sense to hide the noise from runpy as we

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

Changes by Antoine Pitrou : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue16217] Tracebacks are unnecessarily verbose when using 'python -m'

New submission from Matthew Woodcraft: If I run my code using 'python -m' and there is an unhandled exception, the tracebacks include lines from runpy.py (and now sometimes from importlib._bootstrap) which don't provide useful information, and tend to overwhelm the valuable part of the traceba