direct access of import state (e.g. modules replacing themselves in sys.modules)
Eric Snow <[email protected]> Fri, 27 May 2016 15:39:44 -0600
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CALFfu7D2o9-WYmnpY9r2Cwwung62W+qDv3LU228wmxguZc9WVw@mail.gmail.com> |
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