[Python-Dev] PEP 297: Support for System Upgrades

[Guido van Rossum]

> >>Ok, I've started looking at adding support for this. Here's
> >>a couple of things I found:
> >>
> >>* getpath.c:
> >>    Some of the '/' path delimiters are hard coded; shouldn't
> >>    these be replaced with SEP ?
> > 
> > All the platforms that I'm awware of that don't use '/' have their own
> > getpath.c copy anyway (the one for Windows is PC/getpathp.c).
> 
> But can't hurt to change these in the standard getpath.c, right ?
> (reduce() is looking for SEP, so on platforms which do use the
> standard getpath.c but have a different os.sep could be mislead
> by the hardcoded slash in some constants)

-0; it's too painful to think about all the places that would have to
be fixed and how to fix them.

> >>* There's no easy way to find the first item on sys.path which
> >>   starts the default path added by Python at startup time. It seems
> >>   that a suffix search for "python23.zip" gives the best hint.
> >>   The only other possibility I see is writing the support code
> >>   directly into getpath.c.
> > 
> > That's where I'd put it, yes.
> 
> You mean "put it into getpath.c" or "put it in front of
> .../python23.zip" ?

Put it in getpath.c.

> >>* site.py contains code which prefixes "site-packages" with both
> >>   sys.prefix and sys.exec_prefix. Is this really used anywhere ?
> >>   (distutils and the old Makefile.pre.in both install to
> >>   sys.prefix per default)
> > 
> > I thought they might install extension modules in exec_prefix.  But
> > maybe it's a YAGNI.
> 
> Hmm, I've just built a Python interpreter with different
> prefix and exec_prefix settings: using such an interpreter
> lets distutils default to the exec_prefix subtree. However,
> Python itself does not create a site-packages directory in
> that tree (make install creates this directory in
> $(prefix)/lib/pythonX.X/ and not $(exec_prefix)/lib/pythonX.X/).

Probably an oversight in the Makefile.  Doesn't distutils create a
needed directory if it doesn't exist?

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