[Pythonmac-SIG] Why do I need PantherPythonFix?

[Roger Binns]

> Did you read and understand the versioned frameworks blog entry I 
> linked to?  What you're saying has basically no relevance to what I 
> said.

I read it all.  I see the layout.  The section about Mach-O, MH_DYLIB
and dyld tie directly in to what I was asking about ELF, LD_LIBRARY_PATH
and rpath which you said wasn't relevant.
 
> Under certain circumstances, prior to Python 2.3.5/2.4.1, then 
> extensions built on 2.3 would magically work for neither Python 2.3 or 
> 2.4 because they were linked against the 2.4 dylib with 2.3 headers, so 
> you'd get an API mismatch (which is a warning not a hard error, but 
> still..).

Ok, now we are getting closer.  How would one make a failed extension
like this?  On the other platforms extensions end up below the relevant
site-packages directory and distutils ensures the correct header
and library directories are supplied.

On Windows the Python interpretter shared library has a version number
as part of the filename - eg python23.dll.  Consequently, once built
you cannot force an extension to use any other version of Python.

On Linux(ELF) the extensions aren't linked to Python in any way.  The
symbols are unresolved in the extension.  When the extension is loaded 
into a process, they are resolved at that point against the symbols
that exist in the running process.  Consequently you could try to
build an extension against 2.3 and load it into a process with a
2.4 interpretter.  But this never happens in practise because the
extensions are stored in a Python version specific site-packages
directory.

> When Python is built to target Mac 
> OS X 10.3 or later using the "-undefined dynamic_lookup" linker flag, 
> when using PantherPythonFix on 2.3.0, Python 2.3.5, or Python 2.4.x, 
> then extensions are not even linked to the Python interpreter so this 
> problem goes away and the invariant is preserved.

Ok, so that gets the same behaviour as ELF.  And presumably if
someone tried hard enough they could end up with an extension
for 2.3.x running in a process with 2.4.x Python.

On other platforms the extensions always end up in a site-packages
directory below the relevant Python version.  If you have 3 different
Pythons installed, you build your extensions 3 times.

Is there some goal to avoid having to do that on Mac?
 
> I understand your frustration in trying to understand the issues at 
> hand here, but please know that they are tricky but solved.  This topic 
> comes up a lot and I'm pretty tired of talking about it.

I guess the issue is that things are done differently, there appear 
to be some breakages, and then some unstated goals, and finally lots 
of information about fixes for all this, mixed in with various version 
numbers.  The initial thing that came to my mind was "then why do
things differently".  The unstated goals is probably the hardest bit to 
understand.

Is there some attempt to make extensions work with multiple versions,
or did that happen anyway and was a bug?  Is there an attempt to make
extensions compiled on one machine work with the same version of Python
but installed in a different location on another machine?

Jack's list from Friday is a good start since it doesn't require
understanding.  Being in the form of "if your goal is X, then
install Y" helps a lot.  It will also need some idea of what
environment variables (eg PATH) should be set.

>  This can include the Python interpreter, if you are using
>  a Python interpreter shipped with Mac OS X.  Thus your application 
>  may be "tightly bound" to a particular major version of Mac OS X if you 
>  are using the vendor Python.

What is a major version in this context?  (ie is it tightly bound to
version 10 or 10.3.x?) If the former I don't understand why it is even 
mentioned.  If the latter then it appears to be another Mac-ism.  The 
Windows Python works on Win95 onwards.  The Linux one will work on that 
version of Linux and most other ones released after that version.

Roger