[Python-Dev] Sharing expat instances

[Phillip J. Eby]

At 02:19 AM 12/15/2005 +0000, Steve Holden wrote:
>Scott David Daniels wrote:
> > 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.

Actually, the discussion wasn't about eggs, but about the placement of C 
extensions in standard, "normal" package directories.  The Python 
installation uses only top-level C extensions and puts them in separate 
directories.  The question outstanding is, why?  Since there already exists 
exec-prefix for architecture-specific files, and the distutils installs an 
entire package to either prefix or exec-prefix depending upon its "purity".

I suspect that the reason is legacy: originally packages didn't exist, and 
then even when they did, the distutils didn't.  Most of the stdlib is 
developed in-place without benefit of the distutils, so it makes sense 
historically that the modules would be where they are, especially since the 
distutils need some of those modules to run.

However, this alone wouldn't be a reason not to build and install 
ElementTree using the distutils.