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