Re: direct access of import state (e.g. modules replacing themselves in sys.modules)

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. :)

-eric

On Fri, May 27, 2016 at 3:39 PM, Eric Snow <[email protected]> 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