[ python-Feature Requests-1462486 ] Scripts invoked by -m should trim exceptions

[SourceForge.net]

Feature Requests item #1462486, was opened at 2006-03-31 19:23
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nick Coghlan (ncoghlan)
Summary: Scripts invoked by -m should trim exceptions

Initial Comment:
Currently in 2.5, an exception thrown from a script invoked by -m (runpy.run_module) will dump an exception like:

Traceback (most recent call last):
  File "D:\Development\Python25\Lib\runpy.py", line 418, in run_module
    filename, loader, alter_sys)
  File "D:\Development\Python25\Lib\runpy.py", line 386, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "D:\Development\Python25\Lib\runpy.py", line 366, in _run_code
    exec code in run_globals
  File "D:\Development\modules\test25.py", line 53, in <module>
    raise GeneratorExit('body')
GeneratorExit: body

This should probably be trimmed to:

Traceback (most recent call last):
  File "test25.py", line 53, in <module>
    raise GeneratorExit('body')
GeneratorExit: body

to match when a script is invoked by filename.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2006-04-08 16:23

Message:
Logged In: YES 
user_id=31435

I see no reason to bother with this -- it adds complexity,
and I don't see any real benefit.  What's bad about having
runpy show up in the traceback, given that code in runpy.py
actually _is_ in the call stack?  Why try to hide the truth
of it?

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-08 13:28

Message:
Logged In: YES 
user_id=1038590

I can fix it so that the runpy module lines are only masked
out when the module is invoked implicitly via the -m switch
by giving the C code a private entry point
(_run_module_as_main) that catches exceptions and prints the
filtered traceback before doing sys.exit(-1).

I'll make sure to add some tests to test_cmd_line to verify
the updated behaviour.


----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-07 07:12

Message:
Logged In: YES 
user_id=1038590

I'd forgotten about SF's current "no email when assigned a
bug" feature. . .

I'm inclined to agree with Guido that it could be tricky to
get rid of these without also masking legitimate traceback
info for import errors (e.g. if the PEP 302 emulation
machinery blows up rather than returning None the way it is
meant to when it can't find a loader for the module).

OTOH, I don't like the current output for an import errror,
either:

C:\>C:\python25\python.exe -m junk
Traceback (most recent call last):
  File "C:\Python25\Lib\runpy.py", line 410, in run_module
    raise ImportError("No module named " + mod_name)
ImportError: No module named junk

So I'll look into it - if it is suspected that runpy is at
fault for a problem with running a script, then there's two
easy ways to get the full traceback:

C:\>C:\python25\python.exe -m runpy junk

C:\>C:\python25\python.exe C:\Python25\Lib\runpy junk


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2006-04-05 20:45

Message:
Logged In: YES 
user_id=6380

I'm not so sure. Who looks at the top of the traceback
anyway? And it might hide clues about problems caused by
runpy.py.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1462486&group_id=5470