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

Guido van Rossum guido at python.org
Thu Jul 29 00:13:32 CEST 2004

[Guido]

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

[Phillip]

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?

I meant whatever you want. I am not familiar with the need for this functionality, all I know is import hooks and you were clear that those are too low-level.

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'.

Today's import hooks aren't written with recursive import hooks in mind.

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 'safeimp' 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.

Sure. Feel free to build it and propose it as a standard library addition, if you think it will be useful for others. I might even find a use for it -- but right now I'm +0 because I really don't have a need for this stuff in anything I'm doing.

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

But who ever uses module for anything else than printing it?

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list