Chris Jerdonek <[email protected]> added the comment:
Thanks. It looks like the issue with the latest patch is caused by side
effects of calling importlib.import_module().
Working from the patch, I got it to the point where inserting the following
four lines somewhere in the code--
try:
importlib.import_module('foo__doesnotexist')
except:
pass
caused the exception raised by the following line--
module = importlib.import_module('package_foo2.subpackage.no_exist')
to change from this--
...
File "<frozen importlib._bootstrap>", line 1250, in _find_and_load_unlocked
ImportError: No module named 'package_foo2.subpackage.no_exist'
to this--
...
File "..../Lib/importlib/_bootstrap.py", line 1257, in _find_and_load_unlocked
raise ImportError(_ERR_MSG.format(name), name=name)
ImportError: No module named 'package_foo2'
It looks like this issue is cropping up in the tests because the test code
dynamically adds packages to directories that importlib may already have
examined.
In the reduced test case I was creating to examine the issue, I found that
inserting a call to importlib.invalidate_caches() at an appropriate location
resolved the issue.
Should loadTestsFromName() call importlib.invalidate_caches() in the new patch
implementation, or should the test code be aware of that aspect of
loadTestsFromName()'s behavior and be adjusted accordingly (e.g. by creating
the dynamically-added packages in more isolated directories)? For backwards
compatibility reasons, how does loadTestsFromName() currently behave in this
regard (i.e. does importlib.import_module() behave the same as __import__ with
respect to caching)?
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue7559>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
