This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, christian.heimes, ivazquez, jafo
Date 2008-03-27.14:31:01
SpamBayes Score 0.10282198
Marked as misclassified No
Message-id <1206628263.1.0.583069497258.issue1294959@psf.upfronthosting.co.za>
In-reply-to
Content
Placing the entire library tree in /usr/lib64 is wasteful on dual 
32/64bit installation, but placing just the C modules there is contrary 
to python import logic and may cause problems to relative imports.

I have suggested what I believed was a workable solution: have 64-bit 
python search lib64-dynload subdirectories instead of lib-dynload.

See http://mail.python.org/pipermail/python-dev/2007-April/072653.html

Currently $(prefix)/pythonX.Y/lib-dynload is inserted in the sys.path, 
but I think it would be better to handle this inside the importer in a 
way similar to how the importer looks for both foo.so and foomodule.so 
when importing foo. This would allow submodules and user modules treated  
the same way.
History
Date User Action Args
2008-03-27 14:31:03belopolskysetspambayes_score: 0.102822 -> 0.10282198
recipients: + belopolsky, jafo, christian.heimes, ivazquez
2008-03-27 14:31:03belopolskysetspambayes_score: 0.102822 -> 0.102822
messageid: <1206628263.1.0.583069497258.issue1294959@psf.upfronthosting.co.za>
2008-03-27 14:31:02belopolskylinkissue1294959 messages
2008-03-27 14:31:01belopolskycreate