Eric Snow added the comment: (Note that PathFinder.invalidate_caches() loops over sys.path_importer_cache and invalidates the cache of each path entry finder therein. What you're suggesting is clearing sys.path_importer_cache after the loop finishes.)
Hmm. The distinction is between clearing the cache of each finder and clearing the caches in the import machinery, sort of. sys.path_importer_cache effectively belongs to PathFinder, just like sys.path_hooks. I expect they are part of sys only as a historical artifact (i.e. pre-importlib). So I'd say there isn't any conceptual problem in that regard. The point of importlib.invalidate_caches() is to allow finders to pick up out-of-band events. In the case of sys.path_importer_cache, it would allow new entries in sys.path_hooks to have a shot and old entries to have another chance. That seems reasonable. The only caveat I see is that sys.path_importer_cache is not an "internal" cache (as the importlib.invalidate_caches() docs refer to them). Furthermore, it has some established semantics attached: * a path hook will only be called once for a path entry (entries in the cache are fixed in place once added) * None is a sentinel for not-found Consequently,someone may inject None into the cache to prevent finding a spec/loader. With this chance, calls to importlib.invalidate_caches() could cause them problems. In this regard there may be a backward-compatibility issue. Other than that, I consider clearing sys.path_importer_cache in PathFinder.invalidate_caches() to be a reasonable change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26281> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
