Fri, 4 Feb 2000 10:52:20 -0500
Going through the links Greg posted to the dev list discussion,
I find some things that I think need clarification:
> - the core API may be incompatible, as long as
> compatibility layers can be provided in pure Python
From the C API, we have PyImport_Import which does the
same as (keyword) import. But PyImport_ImportModule and
...Ex are lower level. I assume that modulo some arg
munging, these also will do the same as (keyword) import.
> - support for freeze functionality
Heh, heh. The current modulefinder works by (yet again)
emulating the entire import process, but not letting the
"imported" code leak out. In imputil, it's the Importer base
class that does the "leaking", not code in a (well-behaved)
derived class. So that opens the possibility of replacing the
Importer object in the derived class's bases with a
PhonyImporter that doesn't leak. So modulefinder could use
the derived class and wouldn't have to emulate. However,
modulefinder would have to report more information - the
importer that found the module, as well as the
file/URL/whatever it found it in.
> - sys.path and sys.modules should still exist; sys.path
> might have a slightly different meaning
> - Standard import from zip or jar files, in two ways:
> (1) an entry on sys.path can be a zip/jar file instead of a
> directory; its contents will be searched for modules or
> (2) a file in a directory that's on sys.path can be a zip/jar
> file;its contents will be considered as a package
It looks like we're very close to this. Maybe already there
(once a suffix importer has been written for a zip file).
In the current version, items on sys.path can be directory
names or importer instances. Obviously at startup, sys.path is
nothing more that strings. Also (per other discussions),
sys.path starts as a minimal boot path, and gets expanded
What is this mechanism?
Do we worry about:
Network installations in heterogeneous environments?
Ditto in homogeneous environments?
Multiple incompatible installations?
(I vote "yes" on the last two, and "maybe" on the first; mainly
because the latter two can be solved by figuring a boot path
based on the location of the executable).
Should the syntax of .pth files be expanded to allow specifying
importer instances? Or do we use sitecustomize?
Mmph. Enough for now...