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

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dmitry Kazakov]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dmitry Kazakov]

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

--
nosy: +vaultah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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 rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:


--
nosy: +Arfrever

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


--
nosy: +eric.snow

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
components: +Library (Lib)
nosy: +ezio.melotti
stage:  - needs patch

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matthew Woodcraft]

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

--
messages: 172806
nosy: mattheww
priority: normal
severity: normal
status: open
title: Tracebacks are unnecessarily verbose when using 'python -m'
type: enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Changes by Antoine Pitrou pit...@free.fr:


--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick Coghlan]

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

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

--
assignee:  - ncoghlan
nosy: +brett.cannon
versions: +Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16217
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com