[Python-Dev] Fix import errors to have data

[Guido van Rossum]

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

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