[Import-SIG] direct access of import state (e.g. modules replacing themselves in sys.modules)

Eric Snow ericsnowcurrently at gmail.com
Fri May 27 17:39:44 EDT 2016

Currently Python code may directly access the interpreter-global
import state through the sys module.  Sometimes that code only reads
the global import state and sometimes it also modifies it.  One
notable example of the latter is where modules replace themselves in
sys.modules (in order to use a custom module type).

The specific issue of modules replacing themselves in sys.modules has
come up before and the idea of finding a more canonical mechanism to
meet the underlying needs has been at the back of my mind for a while.
Regardless, that's only a part of the broader issue.

Recently I've been prepping for a successor to PEP 406 (import state)
and ran into this broader issue.  The tricky part is that, while the
encapsulation of the import system should be self-contained, external
direct access/modification of global import state (sys.*) _can_ result
in a problematic disconnect from the encapsulated import state.

For any distinct import system that isn't currently active (exposed
via builtins.__import__; state exposed via sys.*), the problem is most
pronounced ( or only a problem?) when a module is being exec'ed.  If
the module code directly accesses import state through the sys module
then that module might not be aligned with the import system that is
currently exec'ing it.  If it modifies the import state then it will
not be aligned.

Here are some options I've thought of:

1. leave things the way they are (uninstalled-but-active import
systems are out of luck)
2. hack builtins.__import__ and sys for the current exec
3. module code should access the current import state through some
other namespace than sys
  a. builtins.import_system
  b. importlib.current_system (or importlib.system.current)
  c. sys.import_system

I'd favor 3c, but for backward compatibility #2 would probably be
necessary in addition.  It may also make sense to give special
consideration to the pattern of a module replacing itself in



More information about the Import-SIG mailing list