[Python-Dev] Python modules should link to libpython

[Bob Ippolito]

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