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.

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.

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

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.

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?

Logged In: YES 
user_id=6380

I'm with Tim. Please close w/o action.

Logged In: YES 
user_id=1038590

Done.