[Import-sig] Requirements

Gordon McMillan gmcm@hypernet.com
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. 
Decent assumption?

> - 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
>   packages
>  (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 
from Python.

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

- Gordon