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

[Nick Coghlan]

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 exceptions triggered via "-m": if we want the unfiltered exception in that case, we can either edit runpy to skip the filtering (when working on runpy), or else call the runpy API directly, rather than via -m.

That means I like the idea of implementing the traceback filtering and display inside runpy._run_module_as_main itself, rather than relying on the default interpreter level traceback display.

One potential approach to that would be to expand the current code that suppresses tracebacks entirely for runpy._Error exceptions to also handle the "except Exception as exc:" case and print out a traceback variants that omits any frames from runpy, importlib, or _frozen_importlib (KeyboardInterrupt and SystemExit would still escape unmodified)

As far as the implementation goes, this could potentially be made a general feature of the new(ish) TracebackException https://docs.python.org/3/library/traceback.html#tracebackexception-objects class by accepting an "ignore_modules" iterable as a parameter to TracebackException.format() and then ignoring frames running code from those modules (conveniently, runpy, importlib, and _frozen_importlib between them will exercise the cases of a single-file module, a self-contained package, and a frozen module, so only namespace package support would end up relying entirely on synthetic test cases).

----------
versions: +Python 3.7 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16217>
_______________________________________