Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 Description of problem: PEP 273 has put /usr/lib/python23.zip in sys.path[1], apparently to improve linear search behavior when loading modules. sys.path[1] used to be a reasonable way to find the preffered installation location in spite of multilib paths and such. This is/was a useful convention imho. PEP 273 concerns regarding linear search behavior are better addressed by, say, hashing all the available modules once. Hashing module paths would seem to be easier to enforce policies like "Prefer zipped before *.pyc before *.py" with only small loss of dynamic lookup if, say, module trees were changing underneath running executable that had already hashed paths. There are obvious timestamp checks that establish lookaside hashed path consistency if that degree of dynamic lookup is a MUSTHAVE. But I digress ... Any chance of reverting to the previous convention, i.e. sys.path[1] contains the "preferred" module installation lpath? Version-Release number of selected component (if applicable): How reproducible: Didn't try Additional info:
There are other ways to look at the installation location: python -c "from distutils import sysconfig; print sysconfig.get_config_var('LIBDEST')" (you'll need python-devel though, unless I move /usr/lib/python2.3/config/Makefile into python, which would be possible too since distutils would break otherwise).
Here's something else that can happen: PYTHONPATH=afdadfasdfadf python -c "import sys; print sys.path" ['', 'afdadfasdfadf', '/usr/lib/python1.5/', '/usr/lib/python1.5/plat-linux-i386', '/usr/lib/python1.5/lib-tk', '/usr/lib/python1.5/lib-dynload', '/usr/lib/python1.5/site-packages'] This is on python 1.5. PYTHONPATH is documented and it will munge sys.path; I think relying on sys.path is bogus in the first place.
Indeed according to Gustavo sys.prefix is what should be being looked at here: python -c "import sys; print '%s/lib/python%s\n' % (sys.prefix,sys.version[:3])" not quite as terse but probably more portable
The above isn't multilib clean as it's hard coded lib, looks like the fragment in comment #1 is probably best for rpm-python as it buildrequires python-devel anyway.
Closing