[Python-Dev] Python modules should link to libpython
Bob Ippolito
bob at redivi.com
Wed Feb 8 20:17:07 CET 2006
On Feb 8, 2006, at 11:02 AM, Ronald Oussoren wrote:
>
> On 8-feb-2006, at 19:55, Martin v. Löwis wrote:
>
>> Gustavo J. A. M. Carneiro wrote:
>>> Any thoughts? Should I go ahead and open a bug report (maybe with
>>> patch), or is this controversial?
>>
>> I can accept that the Mac does it differently, although I think the
>> rationale for doing that is dangerous: you shouldn't really attempt
>> to share extension modules across Python versions.
>
> My explanation seems to be bad, I meant to say sharing extensions
> across
> different builds of the same Python version. One might install a
> normal
> unix build in /opt/python and a framework build in /Library/
> Frameworks.
>
> This is not as important now as it was when Python 2.3.x was state
> of the
> art, then you could have a python 2.3.x framework both in
> /System/Library/Frameworks (provided by Apple) and in /Library/
> Frameworks
> (build yourself or downloaded the official MacPython binaries).
> Those would
> share the same site-packages directory (/Library/Python/2.3).
They never shared the same site-packages directory... The major
reason we use -undefined dynamic_lookup rather than linking directly
to a particular Python is so that the framework can be moved around
without everything going to hell.. e.g., to the inside of an
application bundle. At the time, we didn't have any tools that could
do the Mach-O header rewriting that py2app does now. There isn't a
whole lot of reason to use -undefined dynamic_lookup these days, but
there also isn't many compelling reasons to go back to direct linking.
There is one use case that direct linking would support: having
multiple distinct Python interpreters in the same process space,
which could be useful for writing plug-ins to applications that are
not Python based... Other than that, there's little reason to bother
with it.
-bob
More information about the Python-Dev
mailing list