Martin Panter added the comment: I committed a slightly modified version to 3.5+. I stopped wrapping the new ImportError, and let the existing find_spec() handler wrap it instead. That way the existing error messages stay the same.
However I cannot figure out an easy way to do a similar fix for 2.7, where ImportError.name does not exist. Therefore I propose to leave 2.7 as it is, with just my first commit. This means that 2.7 still omits the traceback if a parent package fails to initialize: $ ./python -m package.submodule [. . .]/python: No module named missing_module It also means we see an unnecessary traceback with broken *.pyc files, although the eventual error message is improved. This case was reported in <https://bugs.python.org/issue19771#msg248193>: $ mkdir bad_pyc $ : > bad_pyc/__init__.pyc # Create empty file $ python2 -m bad_pyc # Original behaviour /sbin/python2: Bad magic number in bad_pyc/__init__.pyc; 'bad_pyc' is a package and cannot be directly executed $ ./python -m bad_pyc # Current behaviour Traceback (most recent call last): File "[. . .]/Lib/runpy.py", line 163, in _run_module_as_main mod_name, _Error) File "[. . .]/Lib/runpy.py", line 111, in _get_module_details __import__(mod_name) # Do not catch exceptions initializing package ImportError: Bad magic number in bad_pyc/__init__.pyc I propose to leave these two cases as they currently are in 2.7, unless someone has any ideas how to improve them. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14285> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
