With 2.7 and now 3.2, we have been supplying two variants of OS X installers: the traditional 32-bit only version dynamically linked with Tk 8.4, the only version available across all supported OS X releases; and a new 64-bit/32-bit version dynamically linked with Tk 8.5 for 10.6 only.  The Tcl/Tk 8.5 version supplied by Apple in OS X 10.6 has proven to work badly with IDLE and other Tkinter applications; issues reported include hangs when pasting text or opening new editor windows or after syntax errors.  Until recently, it was the only standard version of non-X11 Tcl/Tk that was supported for both 64-bit and 32-bit executables.  Recently, ActiveState has released a newer version of Tk 8.5 that is ABI-compatible with the Apple 10.6 one but which behaves much better with IDLE and Tkinter, with none of the previously reproducible hangs detected so far.  Since the Python OS X installer depends on an external source for Tk, either the default Apple-suppled one or, now, an optional 3rd-party install like those from ActiveState, it is important that users are aware that there are options and that they can avoid bad experiences with IDLE crashing, etc.  Because we are dependent on dynamic libraries, it is possible that the situation could change over the lifetime of the Python release, i.e. the Apple could update Tk in 10.6 or new problems could be found.  So the solution here should allow for that.

The attached patches take the following approach:

1. Define a canonical URL on the Python web site for a page that provides the latest status information on supported and recommended Tcl/Tk versions for all recent Python OS X installers.  The URL chosen is:  http://www.python.org/download/mac/tcltk/

2. Add to the OS X Installer Welcome message and ReadMe files prominent references to the new web page.

3. Add an OS X only check in IDLE initialization to see if tkinter is running with the known buggy Apple version.  If so, output a warning message via a print statement executed in the IDLE shell window:

   WARNING: The version of Tcl/Tk (8.5.7) in use may be unstable.
   Visit http://www.python.org/download/mac/tcltk/ for current information.

Since it is possible the user will not be able to install ActiveTcl for some reason (licensing issues, perhaps), issuing the warning through the existing shell window will be much less obtrusive than opening an error window that would need to be dismissed every time IDLE is invoked.

4. Populate and maintain the new web page with the relevant information about OS X installer versions and Tcl/Tk versions.  Make it easy for the user to find do the right thing.  Attached is a first draft of the web page to show the basic approach.

5. Add and maintain references on the main Download page and the release-specific pages to the new web page.  Those changes are also included in the web site patch.

6. Document and publish workarounds for 2.7.1 64-bit installer users.

7. Backport the 3.2 fixes for 2.7.2.

(I'll plan to commit to py3k later today pending any review comments and submit expanded pydotorg changes.)

A comment from the training world:  The instability of IDLE on the Mac makes teaching introductory Python courses a nightmare at the moment.   Sure, one might argue that students should install an alternative editor, but then you usually end up with two problems instead of one.  It would be great if IDLE just "worked" out of the box for starting out.

Glad to see someone looking at this.

This looks good Ned. My main concern is that we make it clear from the *Download* page that users who want IDLE to "just work" (even on 10.6) they should install the 32 bit version.

Noting that Activestate Tcl/Tk 8.5 is a *requirement* for Tkinter/IDLE with the 64bit (10.6) build sounds wise. Just putting it in the installer README isn't enough as it is too late. Obviously fine to put it in the README as *well*.

Having a page linked to from the download page with up to date info on Mac OS X 10.6 is good. You'll probably want website commit rights to maintain this Ned. You can get it by emailing the pydotorg mailing list and preferably should also join pydotorg-www. :-)

Patch for items 2 and 3 committed (with release manager approval for 3.2) in r88003.  Updated the OS X installer build instructions to better reflect current practices including use of A/S Tcl/Tk in r88004.

Pending website changes and 2.7 backport (items 4 through 7).

7. Backported to 2.7 in r88243 (to appear in 2.7.2).

I see this is marked as fixed but pending; perhaps the following comment will be useful.

I encountered the IDLE/Tk instability issue when working on the Homebrew formula for Python-2.6.5 a year ago (March 2010).  Building a universal framework Python on Intel (32/64-bit) produced an IDLE that froze when one created a new window, a common problem even back then.  Attempting to resolve the issue was further complicated by 2.6.5 not having a way to access 32-bit Python in a universal build (since fixed!).

I came up with three workarounds that produced Python builds for 10.6 with an IDLE that at least did not have the new-window freeze.  I'm not a heavy IDLE user, so I didn't test beyond that, and perhaps one or more of the workarounds would still have problems.  Two workarounds could produce 64-bit Python with a non-freezing IDLE; the last one could only produce a 32-bit version, but built on 10.6.

The workarounds:

* As already noted, installing the current ActiveTcl before building Python produced a working IDLE, 32-bit or 64-bit.

* I was able to build a 32/64 universal Cocoa version of Tcl/Tk 8.5 using an 8.6beta backport; I believe I learned of it in the Tcl thread here:

http://mail.python.org/pipermail/pythonmac-sig/2010-March/thread.html

The version I used is on GitHub:

https://github.com/das/tcltk/tree/de-carbon-8-5

I have a brew formula that builds it (at least the version of March 2010) and installs it as a public framework, so Python can find it.  The resulting IDLE did not have the new windows freeze.  If this is a real fix, it might be helpful for users who have license issues with ActiveTcl.

* The last workaround uses the fact that Apple ships both 8.4 and 8.5 versions of Tcl/Tk with 10.6, though the 8.4 Tk is only 32-bit.  I hacked Python's setup.py to detect if a 32-bit 10.6 build is in progress; if so, it linked against 8.4 instead of 8.5, and it produced an IDLE that at least didn't have the new window freeze.  Perhaps 8.4 is old enough to have other issues, but if it would be acceptable as a stopgap, I'm sure Ned et al. could come up with a better setup.py hack than I did.  The advantage of this approach is that it does not require any software that doesn't ship with Snow Leopard.  Since it only works for 32-bit builds, it probably doesn't have advantages over installing the 32-bit 10.3-10.6 Python.  But if you must *build* on 10.6 and have a working IDLE without using ActiveTcl, this might be an option.

I find two things somewhat confusing regarding the current version of the web site:

* My impression was that Python's tkinter figures out what Tcl/Tk to link to at build time, not runtime.  The table on the web site suggests I can use a pre-built Python with an ActiveTcl that I install myself later.  Is this correct?  If so, does ActiveTcl have to be present when the installer is run, or can it be installed later?

* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But the 2.7.2 patched README indicates ActiveTcl-8.5.9 will work.  Will it not work with 2.7.1?

Thanks a lot for your continued work on this thorny issue!

"* My impression was that Python's tkinter figures out what Tcl/Tk to link to at build time, not runtime.  The table on the web site suggests I can use a pre-built Python with an ActiveTcl that I install myself later.  Is this correct?  If so, does ActiveTcl have to be present when the installer is run, or can it be installed later?"

That is correct and ActiveTcl does not have to be present during installation.  The build process determines which framework version of Tcl and Tk to link with, i.e. 8.4 vs 8.5.  However, if a 3rd-party framework build of Tcl and Tk is present in /Library/Frameworks during the build with a version matching that of the /System/Library/Frameworks, the resulting _tkinter.so binary will have the /Library path name embedded and, at run time when _tkinter is imported, OS X will search there first for suitable Tcl and Tk frameworks and, if not found, will fall back to the ones in /System/Library.

"* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But the 2.7.2 patched README indicates ActiveTcl-8.5.9 will work.  Will it not work with 2.7.1?"

No, because at the time the 2.7.1 64-bit installer was built, the Active State 8.5.9 Cocoa Tk had not been released so that installer was built without a 3rd-party Tcl/Tk present in /Library/Frameworks.  While it *is* possible to patch the _tkinter extension module using the OS X install_name_tool to change the search path (see Issue10537 for details), it is not recommended to do so.

I have expanded the tcltk web page (http://www.python.org/download/mac/tcltk/) to include information on how Python chooses which version of Tcl/Tk to link with and more information on Python 2.7.1 plus a succinct warning at the top of the page about the most problematic cases.  That completes the remaining items 4 and 6.

Ned-

Thanks a lot for the clarifications.  Both the tracker and modified
web page have cleared things up for me.

> "* No recommended or alternate Tcl/Tk is indicated for 32/64 on 10.6.  But the 2.7.2 patched README indicates
> ActiveTcl-8.5.9 will work.  Will it not work with 2.7.1?"
> 
> No, because at the time the 2.7.1 64-bit installer was built, the Active State 8.5.9 Cocoa Tk had not been released
> so that installer was built without a 3rd-party Tcl/Tk present in /Library/Frameworks....

I should have been clearer with my question.  I am interested in compatibility
when I build from source, which is why I was consulting the README files.  I
presume Python 2.7.1 will be happy with ActiveTcl-8.5.9 if it's present when
I build from source.  I built 2.7.1 with the TclTkAqua 8.5.9 backport, and
it works for the most part, i.e., IDLE and matplotlib start up fine and appear
to work, for a while.  I don't use IDLE much presently, but I use matplotlib a
lot with the Tk backend, and though it was stable for me with Py 2.6 and
and older Tcl/Tk, the 2.7.1/8.5.9 combo always eventually crashes for me (segfault)
after I've opened and closed a dozen windows or so.  I'll give ActiveTcl a try to
see if theirs is more stable.

That's just a "data point" for you; no need to respond.

Thanks for all your work on MacPython.

-Tom

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/