[Python-Dev] Sharing expat instances

Steve Holden steve at holdenweb.com
Thu Dec 15 03:19:47 CET 2005


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.
> 
When extension modules are to be run from zip files it's difficult to 
avoid a reduction in sharing anyway - without some kind of additional 
mechanism there's no guarantee that two modules with the same filename 
are actually the same library anyway, and there's every likelihood that 
over time several zipped applications will be released containing 
different versions of the same extension module. In that case each app 
would want the version that came with it anyway, no?

There are slightly different requirements for packaged distribution than 
for the standard interpreter, which I assume can always rely on having 
an installed module available as a file (though this might not be 
desirable in the future).

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC                     www.holdenweb.com
PyCon TX 2006                  www.python.org/pycon/



More information about the Python-Dev mailing list