Python 3.4.1 installer on Mac links Python to old Tcl/Tk
nad at acm.org
Fri Oct 3 00:08:50 CEST 2014
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.
nad at acm.org
More information about the Python-list