Nick Coghlan added the comment:
Aye, the report is definitely appreciated - the interaction between "__main__"
execution and normal module imports has always been tricky, so it's always good
to be informed of new problems folks encounter.
As an example illustrating the underlying problem here without involving the
"-m" switch at all:
>>> from importlib.util import find_spec
>>> find_spec("dis")
ModuleSpec(name='dis', loader=<_frozen_importlib_external.SourceFileLoader
object at 0x7fa7ba859fd0>, origin='/usr/lib64/python3.5/dis.py')
>>> import sys
>>> sys.modules["dis"] = object()
>>> find_spec("dis")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python3.5/importlib/util.py", line 99, in find_spec
raise ValueError('{}.__spec__ is not set'.format(name)) from None
ValueError: dis.__spec__ is not set
The difference between 3.5.1 and 3.5.2 is that if you do
"find_spec('mypkg.mymod')" *before* "mypkg" is imported, then find_spec will
use the original module object rather than the replacement inserted into
sys.modules when it recurses down to look for "mypkg.mymod". However, if
"mypkg" is already in sys.modules before find_spec is called, then find_spec
will attempt to use that existing object, rather than the (potentially no
longer available) original module object.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27487>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
