[Python-Dev] Sharing expat instances

Wed Dec 14 22:28:04 CET 2005

Phillip J. Eby wrote:
> At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote:
>> Phillip J. Eby wrote.
>>>>>> my current idea is to
>>>>>>>> 1. include it under a different name (_elementtree.so)
>>>>>>>> 2. add a cElementTree.py under xml.etree, which simply does
>>>>>>>> from _elementtree import *
>>>>>>>> does anyone have a better idea ?
>>> I was under the impression that simply installing cElementTree.so in the
>>> relevant package directory would work; this is what the distutils do for
>>> extensions with a package name.
>> it would work, of course, but the core puts all the binaries in a separate
>> directory (lib-dynload on unix, DLLs on windows, etc).
>>>> do we really want to put executables in other locations ?
>> I don't know. I can see that the split makes sense for prefix/exec-prefix 
> distinctions, but then again, the disutils will install an entire 
> distribution in exec-prefix if it contains "impure" parts, so that's 
> certainly an option here.
>> On the other hand, it's not clear to me *why* the lib-dynload/DLLs 
> directories exist, since it seems to me that that's what exec-prefix is 
> for. Perhaps somebody can explain why lib-dynload/ and DLLs/ 
> exist? Perhaps some platforms have to add these directories to some 
> godforsaken environment variables like LD_LIBRARY_PATH or something?

What I believe I understand about /.pyd / .so / .dll / shared libraries
is that they are meant to allow several processes to map the same disk
backing store to the same same virtual address for more than a single
process. If the .egg strategy is followed, I expect that either the
file shared is in a user(or even process)-specific location or there
is a shared folder that is writable by many processes from which
executable code can be run. The one solution reduces sharing, the
other violates security principles.
--Scott David Daniels
Scott.Daniels at Acm.Org