[Pythonmac-SIG] Main Python on Mac version?

[Bob Ippolito]

On Feb 10, 2005, at 11:51 PM, Roger Binns wrote:

> The standard Python on Mac appears to be the original 2.3.0 release.

The system one that shipped with Mac OS X 10.2 (2.2.0) is pretty much  
unusable, 10.3 does have the original 2.3.0 release.

> Is there any reason this never gets updated by Apple?

Apple's upgrade policy seems to be one of urgency rather than  
convenience.  If there were gnarly security issues in Python, I'm sure  
we'd have seen an upgrade.  There's an upgrade around the corner called  
Tiger (10.4), which will ship with a more recent version of Python.   
Which version this is, I can't say, but the public WWDC 2004 sources  
had 2.3.3 if I'm not mistaken.

> There appear to be several other packages out there that are more
> recent, but it is never clear what they do.  Are they replacements
> for the Apple python?  Do they install alongside it so you have
> two versions?  Why is there nothing on python.org about what
> should or should not be installed and updated?

Only Apple should ever fix Apple's software (`PantherPythonFix`_ being  
the only exception I'd recommend).  Therefore, anything else goes  
somewhere else.  Jack's `MacPython 2.3.5`_ build goes into  
/Library/Frameworks/Python.framework, puts some applications in  
/Applications/MacPython-2.3 and some symlinks in /usr/local/bin.  If  
you want to "replace" the Apple python, then you simply need to change  
your PATH.

As far as documentation goes, we could sure use some.  However, for  
10.3 users, 2.3.0 is usually more than adequate.  The only time I've  
ever needed something newer is for Zope.

> The only Python I care about is the main system one, and would
> prefer it to contain bug fixes.

Well I have slopped together the `Python23Compat`_ package that brings  
in some of the new stuff from Python 2.4, and Jack has a package  
`PantherPythonFix`_ that fixes some distutils nits.

There are some bugfixes that would be nice, but it's dangerous to do  
that because you end up with some people that have a fast datetime  
module and some people with a slow datetime module, or some people with  
a plistlib that works with dates, and other people without.

If you want an application that is 10.2 compatible, then you need to  
build it with a non-system Python (where it, and all of the extensions  
used, were also built on 10.2)
If you want an application that will work, unchanged, far into the  
future, then you should build it with a non-system Python.  There's a  
good chance system-python-dependent applications built on 10.3 will  
work on 10.4, but there's probably not a good chance that such  
applications will work on later versions of Mac OS X (if, for example,  
Python 2.4 becomes the default and 2.3 goes away).

.. _`MacPython 2.3.5`: http://homepages.cwi.nl/~jack/macpython/beta.html
.. _`Python23Compat`:  
http://bob.pythonmac.org/archives/2005/02/02/python23compat/
.. _`PantherPythonFix`:  
http://bob.pythonmac.org/archives/2005/02/04/fix-mac-os-x-103s-python 
-230/

-bob