Python 3.4.1 installer on Mac links Python to old Tcl/Tk

[Ned Deily]

In article <m0jciu$hoi$1 at ger.gmane.org>,
 "Peter Tomcsanyi" <tomcsanyi at slovanet.sk> wrote:
> "Ned Deily" <nad at acm.org> wrote in message 
> news:nad-40CB03.10344701102014 at news.gmane.org...
> > The python.org 3.4.x series of installers will likely never change from
> > linking with Tk 8.5 by default.  That would break a number of important
> > third-party Python packages that supply binary distributions built for
> > the python.org OS X pythons, like matplotlib.
> I respect your decision.
> But it surprises me because the Windows version of Python 3.4.1 already 
> comes with Tcl/Tk 8.6. Does it mean that there are no such problems with 
> matplotlib etc. in Windows?

The main issue is that, unlike MS and Windows, Apple has long shipped 
versions of Tcl and Tk with OS X.  As I understand it, Apple even helped 
sponsor the writing of the newer Cocoa-based Tk that would also work on 
64-bit systems after they decided to not extend the older Carbon APIs to 
64-bit, making the original OS X native Carbon-based Tk problematic on 
newer Macs and releases of OS X.  When the Cocoa Tk was first shipped 
with OS X 10.6, Tk 8.6 hadn't been released yet so they went with a 
backport to 8.5 and, for whatever reasons, Apple has been very slow to 
upgrade their 8.5.x Tk since then and have not shipped a 8.6 version 
yet.  That leaves us in a bit of a quandary for the python.org 
installers.  Ideally, we'd just like to continue to depend on an 
Apple-supplied version but even the most recent releases of OS X ship 
with serious bugs.  Fortunately, it's been possible and long been our 
practice to ship the python.org installers Pythons built in such a way 
that, at run time, they will automatically use a compatible third-party 
Tcl and Tk, if present, otherwise fall back to the system version.  By 
far, the leading third-party distributor of Tcl/Tk is ActiveState and 
they are actively involved in the development and maintenance of Tcl and 
Tk.  But, their releases are not open-source and have a license that, 
while generous, do not permit totally unrestricted usage.  Thus it is 
problematic to depend totally on their releases. So, to really support 
Tk 8.6, the only viable option at the moment would be for us to ship our 
own versions of Tk, like the Windows installer does.  But it wouldn't be 
acceptable, IMO, to force other projects and users to migrate to 8.6 in 
the middle of a release cycle, e.g. 3.4.x or 2.7.x.  Providing it as an 
option, though, would be OK.

> I think that one of the point when advertising Python is that it works 
> accross the platforms, so keeping one platform (mac) "behind" for months 
> seems to me going against the multiplatform promise of Python...

I don't think we mean to imply that all of the third-party libraries 
that Python is able to use are the same across all platforms.  It 
depends on the platform and the practices there.  The fact is that Tk 
8.5 is still the de facto standard for OS X 10.6+ and Tk 8.4 is the de 
facto standard for OS X 10.5 and earlier systems, because that's what 
Apple has shipped.  And that's why matplotlib et al and we still ship 
binary installers for OS X with 8.5 support.  Third-party open source 
packages distributors, like MacPorts or Anaconda, can more easily move 
to newer versions of things, like Tk 8.6, because they provide complete 
solutions for many applications and libraries: they have ports for 
matplotlib, numpy, pythonx.x, Tk, and all other dependencies.  The 
python.org installers have a much more limited scope.

-- 
 Ned Deily,
 nad at acm.org