[Python-Dev] Python modules should link to libpython (original) (raw)

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