In article <m0jciu$hoi$1...@ger.gmane.org>, "Peter Tomcsanyi" <tomcsa...@slovanet.sk> wrote: > "Ned Deily" <n...@acm.org> wrote in message > news:nad-40cb03.10344701102...@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, n...@acm.org -- https://mail.python.org/mailman/listinfo/python-list
