[Import-sig] Requirements

Guido van Rossum guido@python.org
Fri, 04 Feb 2000 14:26:34 -0500

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

I suppose you mean they should do the same in the new design, because
they would only be there for b/w compatibility?  Right now they are
designed to be different -- in particular PyImport_Import() calls
__import__() calls PyImport_ImportModule[Ex]().

Do we want to keep the override-__import__ hook?

Who else uses PyImport_ImportModule[Ex]()?

> [Guido]
> > - 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.

Actually, it uses a wrapper around imp.find_module() that checks for a
few special cases and otherwise hands the query off to
imp.find_module()!  ( I don't understand why there's a special case
for looking in the Windows registry; find_module() should already do
that, too.)

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

I'm afraid you've lost me here.  What does "leaking" refer to?

> [Guido]
> > - sys.path and sys.modules should still exist; sys.path 
> > might have a slightly different meaning
> and 
> > - 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?

Look at Modules/getpath.c and PC/getpathp.c.  Or are you asking about
how the mechanism should be redesigned?

> Do we worry about:
>  Network installations in heterogeneous environments?

Yes, by supporting sys.exec_prefix.  This has consequences for
getpath.c, see there.  I think this support has lost its significance
with the advent of fast disks, but I'm not going to fight millions of
sysadmins stuck in the past, so we have to continue to support it.
It's no big deal anyway.

>  Ditto in homogeneous environments?

How can you even tell?  Maybe I don't understand what you are talking
about (and then my previous response also doesn't make sense?)

>  Multiple incompatible installations?

Emphatically yes.  A Python binary should be able to find out where
the rest of its installation is.  This is a platform specific problem
(hence getpath.c and PC/getpathp.c).

Note that on Windows there's the added problem of Mark Hammond's COM
support.  COM services implemented by Python can be started on the fly
without starting python.exe, e.g. by embedding such a COM object in a
Word document.  The consequence of this (I've been told) is that the
python15.dll file must live in the system directory (\WinNT, \Windows,
etc.).  This means that its path is useless to find the rest of the
installation, and that's why we're using the registry.

I don't know if all of this is still true; I would think that if a COM
support DLL lives somewhere else, the registry could point to it?  But
who am I to argue with Microsoft.

Anyway I wouldn't mind if this was somehow solved differently; for
example there could be another copy of python15.dll in the Python
install dir which was used normally, and in that case the registry
wouldn't be needed.

> (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?

Do you really think that will be used?  There would seem to be a
chicken/egg problem.

--Guido van Rossum (home page: http://www.python.org/~guido/)