Bug 111438 - PEP 273 changes sys.path[1] value
PEP 273 changes sys.path[1] value
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: python (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mihai Ibanescu
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-03 13:06 EST by Jeff Johnson
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-05 16:38:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Johnson 2003-12-03 13:06:41 EST
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:
Comment 1 Mihai Ibanescu 2003-12-03 13:26:37 EST
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).
Comment 2 Mihai Ibanescu 2003-12-03 13:35:21 EST
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.
Comment 3 Paul Nasrat 2003-12-03 17:11:31 EST
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
Comment 4 Paul Nasrat 2003-12-04 06:47:27 EST
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.
Comment 5 Mihai Ibanescu 2004-04-05 16:38:37 EDT
Closing

Note You need to log in before you can comment on or make changes to this bug.