[Python-Dev] imputil and modulefinder replacements

[Gordon McMillan]

[James C. Ahlstrom]

> My interest in imputil and ImportManager is to implement jar
> files, and neither does this well.  The problem is always how to
> get the SpecialImporter.py imported first, and how to hack the
> imports that the SpecialImporter.py may need to import.  In
> iu4.py we see the use of posix.stat to replace the os module, and
> the import of only built-in modules sys, imp, and marshal.  The
> same is true of imputil.py.

Here's my bootstrap code (archive_rt knows how to import 
from .pyz archives):

import archive_rt, iu4
iu4._globalownertypes.insert(0, archive_rt.PYZOwner)
iu4.ImportManager().install()

Now a .pyz on sys.path will be searched. Nothing hard about 
doing this for a .zip. MacPython & Jython do it.

> I admit I don't really understand package imports.  But I feel
> they are an unsolved problem, because package authors always seem
> to write custom ones.

Most of what I see is namespace trickery, not custom 
importers.
 
> A first-class solution would have these features IMHO:
> 1) Access to libraries in zip files is implemented in C (I
> volunteer). 2) All Python library modules can be imported by C
> code,
>    either from directories or zip files.

With Thomas's changes to PyImport_ImportModuleEx, this is 
largely taken care of (it gets routed through __import__). So 
with the above bootstrap code, C code will import from my 
.pyz as well.

> 3) Package import is not implemented in C, it is implemented
>    by a Python module which is part of the standard library.

The rules aren't documented, but the essentials are pretty 
straightforward. I'd like to see them changed to draw a 
distinction between relative imports and absolute imports 
(since that's a constant source of gotcha's).

However, there are import hacks out there that rely on 
undocumented (and probably accidental) features of 
implementation.

> 4)
> If an import of A.B is attempted, and a function
>    A.MyCustomImporter() exists, then that is used instead of the
>    default.

In iu4, A is welcome to take over all imports below A. If 
A.__init__ does not do so, the standard mechanism is used.

> 5) More or better ideas from you all.



- Gordon