Binary compatibility across Python versions?

[Ned Deily]

In article <0A4C9B21-6EFF-461A-B15C-415D1408DD88 at semanchuk.com>,
 Philip Semanchuk <philip at semanchuk.com> wrote:
[...]
> Thanks to all who replied on this topic. A little more background --  
> these binaries are just a convenience for our users and we don't have  
> to cover every possible permutation of Python, only the ones we think  
> will be most common in our user base. That said, thanks to the things  
> you pointed out, I'm beginning to think that our users might be such a  
> varied group that precompiled binaries might not be worth the trouble.
> 
> Ned, I'm on Mac and I was under the impression that the deployment  
> target compiler option would control how the resulting binary (in this  
> case, Python) called OS X but it wouldn't have any affect on how other  
> code (like our library) called Python. Is that not the case?

Even if your extension modules and libraries don't make a lot of system 
calls, I think it's a bit of a crap shoot since there are no guarantees 
of compatibility among the various popular distributions and there are 
the gcc-4.0 vs -4.2 and the arch differences.  You'd have to try the 
various combinations and/or limit the configurations you support. The 
bottom line is that many (most?) package developers have given up on 
trying to supply binary distributions for OS X.  Since Apple supplies 
the necessary developer tools for free with recent OS X releases and in 
most cases Distutils does the right thing, the burden on end users isn't 
particularly onerous (see, for example, 
http://appscript.sourceforge.net/py-appscript/install.html).

Now, adding SWIG and C++ to the mix may result in a different answer.  I 
don't have any practical experience with them to have an opnion.  Good 
luck!

-- 
 Ned Deily,
 nad at acm.org