[Python-Dev] Sharing expat instances (original) (raw)

Scott David Daniels Scott.Daniels at Acm.Org
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 LDLIBRARYPATH 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

More information about the Python-Dev mailing list