[Python-Dev] Sharing expat instances

[Scott David Daniels]

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