"python -m module" calls the C RunModule() function. If this function fails, the traceback is not displayed and so it is difficult to understand why the problem is.

I propose to display the traceback when this function fails, as it is already done on runpy._run_module_as_main() failure.

Huh? Demonstration please, as the -m switch absolutely does display tracebacks when the call fails:

$ python -m timeit -s "raise RuntimeError"
Traceback (most recent call last):
  File "/usr/lib64/python2.7/timeit.py", line 298, in main
    x = t.timeit(number)
  File "/usr/lib64/python2.7/timeit.py", line 194, in timeit
    timing = self.inner(it, self.timer)
  File "<timeit-src>", line 3, in inner
    raise RuntimeError
RuntimeError

The only tracebacks it suppresses are those for ImportError during the search process, which is deliberate:

$ python -m missing
/usr/bin/python: No module named missing

It even avoids suppressing the traceback when the module is found and an import error occurs later:

$ python -m timeit -s "import missing"
Traceback (most recent call last):
  File "/usr/lib64/python2.7/timeit.py", line 298, in main
    x = t.timeit(number)
  File "/usr/lib64/python2.7/timeit.py", line 194, in timeit
    timing = self.inner(it, self.timer)
  File "<timeit-src>", line 3, in inner
    import missing
ImportError: No module named missing

Never mind, I just looked at your patch and better understand what you're wanting to improve (i.e. diagnosing problems with bootstrapping runpy itself, not the errors that occur after runpy has already been found).

However, your proposed solution is questionable since it may produce spurious output when RunMainFromImporter() is executed.

Is it really so hard to do "python -c 'import runpy'" to further diagnose the problem that the bootstrapping reports?

Taking a closer look at the four affected cases, I've changed my mind - the patch looks reasonable, go ahead and add it (as the new output actually still makes sense in the RunMainFromImporter case)

However, additional test cases should be added to test_cmd_line_script, at least for the two that are fairly easy to test:

- runpy import failure: shadow the stdlib by creating a runpy.py that raises RuntimeError at the top level
- runpy attribute lookup failure: shadow the stdlib with an empty runpy.py

I have no idea how you could force the latter two errors, though, so I'm fine with leaving those paths untested (while tests would be great if you can figure out some way to make the decoding and argument construction steps fail, I expect the use of the surrogateescape error handler will make that very hard to do).

New changeset 39b9b05c3085 by Victor Stinner in branch 'default':
Close #14439: Python now prints the traceback on runpy failure at startup.
http://hg.python.org/cpython/rev/39b9b05c3085

Testing the patch manually is simple: add anything wrong in runpy.py and run "python -m base64".

Output:
---
Could not import runpy module
---

Output with the patch:
---
Could not import runpy module
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 264, in <module>
    x
NameError: name 'x' is not defined
---