[Python-Dev] Fix import errors to have data

[Phillip J. Eby]

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