Tom Loredo <lor...@astro.cornell.edu> added the comment: 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! ---------- nosy: +tloredo status: pending -> open _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue10907> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
