[Python-Dev] Fix import errors to have data (original) (raw)

Phillip J. Eby pje at telecommunity.com
Wed Jul 28 23:14:57 CEST 2004

At 01:44 PM 7/28/04 -0700, Guido van Rossum wrote:

> And for those very large projects, I'm wondering if what is really > wanted is actually to be able to isolate plug-ins or extensions into > their own "module space", similar to the way the Java "classloader" > hierarchy works. [...]

You can certainly build all that using import hooks. But perhaps that's too low a level, and a higher-level infrastructure would be helpful? Import hooks have been around for ages and many improvements have been proposed but few of those have actually found much use (or even found to be real improvements).

Sorry, I'm confused. By "higher-level infrastructure", are you meaning a way to co-ordinate import hooks, or something higher-level than the "module spaces" concept?

As far as I can tell, a properly implemented module space should allow arbitrary import hooks to be used within that module space, so long as the hooks obtain their copy of 'sys' using the previous value of 'import'. For example, if you create a hook using 'import ihooks' within a given module space, then that space's copy of 'ihooks' will see the space's copy of 'sys', so it will thus do all its magic using the right 'sys'.

The weak spot is 'imp', and any other C-coded modules that access the "real" 'sys' module directly (e.g. 'builtin'). These modules would have to be replaced by "safe" versions. E.g., a 'safe_imp' in Python that explicitly passed in a path to the "real" imp functions, and so on. Finding all of the modules that do this and providing "safe" replacements (while making sure that truly global "sys" attributes are shared) would probably be the biggest task in creating a Java-like import framework.

(Oh... and another infrastructure-level issue: Python classes know their module name, but in a system using module spaces, the module name alone is not sufficient to identify the module where the class originated. In Java, a class is uniquely identified by the combination of its fully qualified name, and the classloader used to load it. This is not an issue for Python functions (which reference the module globals) or for modules themselves, which both indirectly refer to the loader used to load the module. But it could be an issue for classes.)

More information about the Python-Dev mailing list