How to update tcl-tk?

The first update to Python by Apple in five years occurred in Catalina as Python 2.7.16. Unfortunately, Apple compiled it against the Tk/Tcl 8.5.9 libraries, and that is all it can use. Here is the output from Python 2.7.16 on Catalina 10.15.1:

and the code that generated that output:

#!/usr/bin/python
# coding: utf-8

import sys

try:
    import Tkinter as tk      # Python 2
except ImportError:
    import tkinter as tk      # Python 3

print("Tcl Version: {}".format(tk.Tcl().eval('info patchlevel')))
print("Tk Version: {}".format(tk.Tk().eval('info patchlevel')))
sys.exit()

Tk/Tcl is deprecated in Catalina, and only the installation of Python.org's Python 2.7.17, or Python v3.8.0 will get you the current Tk/Tcl v8.6.6 which is built into the installation. These can be installed without stepping on Apple's Python distribution, but are referenced from /usr/local/bin, so you would have to preface your PATH environment statement with it.

None of the Python versions shipped by any release of OS X or macOS ever upgraded their Tk/Tcl version support beyond 8.5.9. Newer Tk/Tcl library support must be compiled into the Python interpreter.

Also, on Catalina and a departure from previous, Apple has now included a reduced functionality Python 3.7.3 interpreter within Xcode 11.1 or in the Command Line Tools for Xcode 11. Python3 is located in /usr/bin and gets in the way of the Python.orgs Python3, without special counter-measures.

Installing the current Python 2.7.17, or 3.8.0 binary distributions from Python.org delivers python installations with Tk/Tcl 8.6.6 support built-in. This provides the normal Cocoa interface instead of the older Carbon views. The ancient Apple Tk/Tcl v8.5.9 is entirely ignored.

These get installed into /Applications, /usr/local/bin, and /Library/Frameworks/Python.framework without compromising Apple's installed versions. One just needs to adjust their PATH to lead with /usr/local/bin.

Not me. Although I have some legacy Python apps here using it, Tk/Tcl 8.6.6 has changed some of the 8.5.9 module names (e.g. tkfiledialog to filedialog) so older code will bork, and die without proper attention to import statements, module name changes, and current syntax. Life is too short.

When I tried to run the Python code I posted above using Apple's Python3 that the command-line tools for Catalina installed, it blew up, almost as though they did not compile it against any Tk/Tcl version. It does not include idle3 either because it is based on Tk/Tcl code.

The Catalina installed Python 2.7.17 does support the Cocoa bridge, so handwritten PyObjC code still works. Whew.

You can build local versions of both Python and Tcl/Tk. I wouldn’t recommend any “brew” or “ports” packages. I have seen too many people get their environments scrambled. And since they have never actually installed any local software or learned how shells work, they can’t fix it and are stuck forever.

For the first time since OS X Lion (Python 2.7.5), Apple has included a Python (3.7.3) interpreter with the current Command Line Tools for Xcode 11. It is installed into /usr/bin, and lacks compiled in support for Tk/Tcl (any version). The Tk/Tcl version checking script that I posted earlier originally had #!/usr/bin/env python3 in it, and worked fine with Python.org's v3.8.0 that was installed before the Command Line tools.

Without Tk/Tcl support, Apple's python 3.7.3 just explodes when running the script. I could have just changed the script from python3 to python but it was late, I was PO'd and just wrote it the way it was posted.

The other thing that I noticed was that I had purposely modified my PATH to have /usr/local/bin precede $PATH, and instead of the script using python 3.8.0 with its built-in Tk/Tcl 8.6.6, it used the demented Apple python 3.7.3.

I have a custom stack of GIS tools for some future projects. One of the components is a build of Python. I don’t need much out of it, just enough to make GDAL happy. I don’t need Tcl/Tk.

This is why you should use "/usr/bin/env python” in shebang lines instead of the path. That way, if you have some kind of funky, custom build of something, it will use the correct build based on your current environment.

Would you still need Tcl/Tk 8.6.6? I haven't built any of this in years.

Good.