Martin Panter added the comment:
The relevant code is in the _get_module_details() function at Lib/runpy.py:101.
There are a few of things going on:
1. The code is calling importlib.util.find_spec("<package>.__main__"), and
handles various kinds of exceptions by wrapping them in an ImportError, adding
the “Error while finding spec” message. The call apparently causes the package
to be imported, so some exceptions triggered by running __init__.py are
wrapped. It would be nice if exceptions raised by running __init__.py were not
caught, but I have no idea if this is practical or how to do it. It seems the
exception handler is there to raise ImportError if you do something like
“python -m os.path.something”, which seems rather unlikely to me.
2. The logic for handling the __main__ module in a package seems to assume that
any ImportError (such as raised from step 1) is due to the __main__ module not
being present. Then it wraps that exception in another ImportError, adding the
“. . . cannot be directly executed” bit. Again, it would be good to separate
the __init__.py running from this exception handling.
3. Finally in _run_module_as_main(), the ImportError is caught and printed,
without any traceback. It would be good to only do this for internal errors
loading the module, and not if ImportError is raised when the module (or
__init__.py) is run.
I’m not sure what the best way to fix this is. Perhaps add an internal
ImportError subclass (or subclasses) that is only used for the “No module named
. . .” errors, or only used for errors appropriate for final handler in step 3.
----------
_______________________________________
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
