[Import-sig] Requirements

Guido van Rossum guido@python.org
Fri, 04 Feb 2000 17:07:04 -0500


[Guido]
> > 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?
[Gordon]
> We need a builtin function (so you can use a runtime arg; and 
> not be forced to exec). But there's not much sense in making 
> it hookable, when the whole import system is a set of hooks.

Agreed, except for b/w compat.

> > Who else uses PyImport_ImportModule[Ex]()?
> 
> In my experience, almost all extension writers use 
> PyImport_ImportModule, not PyImport_Import. I think this is 
> speed-freakism, not for functionality (which could only be to 
> avoid hooks).

I think that's more likely because for a long time,
PyImport_ImportModule() was the only interface -- PyImport_Import()
was added much later (by Jim F who needed access to the hooked code
from inside cPickle).

> > > 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?)
> 
> Terms: by "heterogeneous" I meant, eg, a Solaris server with 
> Solaris, Windows and Linux clients. By "homogeneous" I 
> meant clients (and probably server) are all binary compatible.

OK, I knew that.

> I *think* "homogeneous" is more-or-less solved when "multiple 
> incompatible installations" is solved.

I don't see any problems with homogeneous environments -- what
possible problem could there be (that doesn't exist when there's no
sharing and that isn't caused by multiple versions)?

> The added complexity of "heterogeneous" being the plat_xxx 
> libraries (and what package authors have to do), which 
> appears to be getting deprecated(?).
> 
> > >  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).
> 
> Um, yes and no (to it being platform specific). Yes in that you 
> can't follow symlinks on Windows, or easily get the absolute 
> path name of the executable in some *nixen. No, in that I feel 
> strongly (modulo some of the COM stuff below) that the 
> psuedo-code should be the same - just think of distutils and 
> package authors!

The pseudo code is also different because the structure of
site-packages etc. is different on Windows (it doesn't exist).

But I agree that it's a shame that there are two copies of code with
very similar functionality, and I'd gladly get rid of one.  (There's
even a third copy, in the os2 subdirectory!)

> > > 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.
> 
> Categorizing it doesn't solve it ;-). OK, we don't need a 
> concrete solution now, but is this a reasonable approach?
> 
> 1) Py_Initialize calls getpath.c
> 2) getpath.c returns a directory (or very short list thereof).
> 3) Fredrik drives his truck through (me too)
> 4) A frozen-in exceptions.py gets imported
> 5) sys.path gets expanded by looking for (something | some 
> things) in the existing sys.path and ( executing | reading ) 
> them.
> 
> Maybe 3 & 4 are swapped?

Yes, better.

> Maybe some of this is written in Python and frozen in?

Possibly.

> The, err, obsession here being to make it (1) highly 
> customizable AND (2) generally idiot-resistant. A few simple 
> controls under a bright red hatch cover that says "Warning - 
> touching this stuff will void your warranty".

Good metaphor.

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