[Python-Dev] PEP 297: Support for System Upgrades (original) (raw)

M.-A. Lemburg mal@lemburg.com
Mon, 06 Jan 2003 23:20:41 +0100

Guido van Rossum wrote:

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)

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

* site.py contains code which prefixes "site-packages" with both sys.prefix and sys.execprefix. 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 execprefix. 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/andnot(prefix)/lib/pythonX.X/ and not (prefix)/lib/pythonX.X/andnot(exec_prefix)/lib/pythonX.X/).

-- Marc-Andre Lemburg CEO eGenix.com Software GmbH

eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/