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

Eric Snow ericsnowcurrently at gmail.com
Sun May 29 18:10:28 EDT 2016

Looking through all the code, I don't think it's worth it (for now) to
worry about using an import "system" that isn't hooked up to the
import state in sys.  I'll still look into a more isolated import
"system" abstraction later through. :)


On Fri, May 27, 2016 at 3:39 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> 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
> sys.modules.
> Thoughts?
> -eric

More information about the Import-SIG mailing list