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 traceback.

I suppose this is in some sense a regression from Python 2.4.


echo fail > fail.py
python3.3 -m fail

python -m fail
Traceback (most recent call last):
  File "/usr/lib/python3.3/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.3/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "./fail.py", line 2, in <module>
    fail
NameError: name 'fail' is not defined

Here I think it would be better to omit the first two traceback entries.


Syntax errors are worse:
echo syntax error > fail.py
python3.3 -m fail

Traceback (most recent call last):
  File "/usr/lib/python3.3/runpy.py", line 140, in _run_module_as_main
    mod_name, loader, code, fname = _get_module_details(mod_name)
  File "/usr/lib/python3.3/runpy.py", line 114, in _get_module_details
    code = loader.get_code(mod_name)
  File "<frozen importlib._bootstrap>", line 981, in get_code
  File "<frozen importlib._bootstrap>", line 313, in _call_with_frames_removed
  File "./fail.py", line 1
    syntax error

Here there are four traceback entries which could be omitted.

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 well.

Flagging 3.3 for the moment, but if the change is too intrusive it will end up being 3.4 only.

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...

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, tracebacks of exceptions occurring in get_code are kept unmodified.

Would it be wrong to drop all importlib frames from all unhandled exceptions, except when the -v flag is present? On the other hand, since the patch from #issue15486 seems to work fine in most scenarios, I propose removing both runpy and importlib traceback entries locally inside the runpy module. There may be better solutions, though...

In any case, I'm willing to write a patch.

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).

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 request for its implementation?

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.

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, rather than the current directory).