Guido van Rossum
Fri, 04 Feb 2000 17:07:04 -0500
> > 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?
> 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 )
> Maybe 3 & 4 are swapped?
> Maybe some of this is written in Python and frozen in?
> 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".
--Guido van Rossum (home page: http://www.python.org/~guido/)