IDLE 2.6.1 locks up on Mac OS 10.6 when running using Apple's built-in 
version of Python (also 2.6.1) when creating a new buffer window or 
attempting to run/debug an existing file.

If I understand you correctly the same also happens with the current 
version in subversion.

To reproduce:
* Start IDLE.app
* Open a new window

The new window opens, but (1) without a proper titlebar, and (2) this 
makes it impossible to further interact with IDLE (and that includes 
quiting the application).

I can confirm this is the same issue.

I'm willing to leave this as a release blocker for 2.6.3, but I will
re-evaluate it if no progress is made on it.

I can confirm this as well. It also locks up when pasting text. The EDIT 
menu retains its glow, and the pasted text appears after a few seconds, 
along with another blank square window titled "idle". Idle then locks up. 
Using the scrollbar in any way (even by using the mousewheel) also locks 
up IDLE, although the window scrolls perfectly well.

The bug with the edit menu sounds like the same issues I noted in 
http://bugs.python.org/issue6463. I think it was related to something in 
Tk-Cocoa 8.5, which was resolved in a later build of Tk, and which is why 
I closed the bug. The build of Tk-Cocoa that ships with Snow Leopard may 
have preceded the bug fix (there has been a lot of activity on the Tk-
Cocoa front in recent weeks). If that's the case, I doubt a fix will be 
available unless Apple updates its core Tk libraries. The best workaround 
might be to install an updated build from the source 
http://github.com/das/tcltk/tree/de-carbon-8-5 into /Library/Frameworks.

kevin: do you know if there is a plain Tcl script that shows the bug? If 
there is we can file a bugreport with Apple that clearly shows a problem 
in the Tk framework and hence makes it more likely that the issue will get 
fixed.

Ronald: No, unfortunately I was never able to reproduce the bug in pure 
Tcl. I tried various examples with the Tk text widget. I also tried 
various examples with the text widget via Tkinter. Each time the text 
widget, cutting, pasting, etc. worked as expected. I suspect the bug is 
somewhere in IDLE's interaction with that iteration Tk-Cocoa, but I could 
not pinpoint it.

Here's a status update:

After testing 2.6.3-pre-rc1 with various combinations of Apple and 
ActiveState Tk 8.4 and 8.5 on 10.5 and 10.6, so far I have only seen the 
"new window hang" problem with Apple's Tk 10.5 (10.5.7) as supplied with 
10.6 Snow Leopard.  Although the Apple-supplied 2.6.1 IDLE runs in 64-
bit, the same hang shows up with Apple Tk 8.5.7 in 32-bit mode as well 
(this with a 32-bit 2.6-svn IDLE built on 10.5 in the manner of the 
standard python.org installers except with AS 8.5 Tk installed during 
the build).  Running this last installer on either 10.6 or 10.5 with AS 
8.5.7 installed (32-bit only), I have been unable to reproduce the "new 
window hang".  However, there are some other serious issues that I am 
still investigating.

The good news is that, so far with one exception and with admittedly 
light testing, I have seen no regressions on either 10.6 or 10.5 using 
Tk 8.4 with 2.6 svn: Apple Tk 10.4.19 on 10.6, Apple Tk 10.4.7 on 10.5, 
AS Tk 10.4.19 on either 10.5 or 10.6.  The exception is documented in 
Issue6951 with a supplied patch that should be go into 2.6.3.

Even without the Tk problems, it is also unfortunate for IDLE users that 
the Snow Leopard Python is 2.6.1; a number of problems with IDLE on OSX 
were fixed in 2.6.2.

So, with more work to be done, my recommendation at this point is to 
assume 2.6.3 can be released with an OS X installer dynamically linked 
as in the past with Tk 8.4 (so usable with either the system Tk 8.4 or a 
user-installed AS 8.4) and deployable on 10.3.9 through 10.6 on 32-bit 
Intel and PPC, where applicable.  Pending further investigation and 
resolution, we should say that 2.6.3 does not support Tk 8.5 on OS X - 
period.

I don't understand the logic of saying that IDLE in Python 2.6.3 will not 
support Tk 8.5 in any fashion when you say that it runs fine with 
ActiveState Tk 8.5. 8.4 is obsolete. The "new window hang" bug is specific 
to the version of Tk 8.5.7. If ActiveState's build works, then why not say 
you need to install your own version of Tk 8.5 for it to work?

@Kevin: I didn't say it runs fine with ActiveState TK 8.5.7; that's what 
the "other serious issues" refer to.  I need to do some more work to 
isolate those problems.

I agree that we should mention in the news file that Apple's version of 
Tk 8.5 in Snow Leopard causes problems with IDLE.

W.r.t. Tk 8.4 vs. 8.5: the 2.6 binary releases will be linked to Tk 8.4 
because of two reasons. Firstly all 2.6 releases upto now were linked 
with Tk 8.4, and secondly IMO it is important that IDLE.app works out of 
the box on all supported OSX releases.

I'm willing to review patches for 2.7/3.2 that enable shipping two 
copies of _tkinter.so in the installer and automaticly selecting the 
best one at runtime (that is, ensure that import _tkinter imports the 
8.5 version when that is available and the 8.4 version otherwise).

To explain my previous entry about shipping 8.4 and 8.5 versions of 
_tkinter, one way to implement this is:

* Build two copies of _tkinter.so: _tkinter84.so and _tkinter85.so
* Add _tkinter.py to Lib/plat-mac with the following contents:

    try:
       from _tkinter85 import *
    except ImportError:
       from _tkinter84 import *

The problem is *not* reproducible using the trunk (2.7). 

I haven't been able to isolate the change that fixes the issue. As a 
quick hack I replaced _tkinter.so and Lib/idlelib/*.py in a 2.6 tree by 
the same files from the trunk. That didn't fix the issue, which probably 
indicates that some unrelated checkin accidently fixed the issue in the 
trunk.


Both the trunk and 2.6 have a menu named "IDLE" to the right and have 
"About Tcl/Tk" in the application menu. (This is when using Apple's Tk 
8.5 on OSX 10.6). That might be fixed by the patches in issue 6075.

I'm re-prioritizing this as "high" because the binary installer won't 
suffer from this issue and there is no straightforward bugfix.

I also can verify that the problem is not reproducible using a current 
trunk (2.7) and the 10.6 Apple Tk 8.5.7.  Further testing of this issue 
with both Apple Tk 8.4.x and ActiveState Tk 8.4.19 on 10.4, 10.5, and 
10.6 has been hang-free.

It looks like there were a number of fixes to _tkinter.c and friends 
checked in by Guilherme early in 2009 that were not backported to 2.6 
and some of them have to do with thread locking.  Whether or not the 
fixes should have been backported is not an issue at this point. However 
I think it makes little sense to attempt much further work on this 
problem using the current 2.6 base without looking at backporting first.

So, with regard to the 2.6.3 release, I concur with Ronald's plan to 
continue to link only with Tk 8.4 for the OS X installer and I suggest 
there be a disclaimer somewhere about building with Tk 8.5 on OS X for 
2.6.3.

I'm thinking that the Snow Leopard abort trap when invoking IDLE from the command line is a permissions problem somewhere because it works ok when invoked with sudo. The console displays an odd message "2010-08-07 20:38:23.375 Python[25858:170b] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs" is the only thing out of the ordinary.

This is out-of-the-box 2.6.1

Richard: I don't understand your message. What abort are you talking about?

Sorry to be obscure, Ronald. I mistook my configuration problem, described below for the original problem. But I can reproduce the problem with opening an existing file under IDLE, which is a segmentation fault. When opening a new window, I get a blank screen but no >>> prompt.

I should have done this before on my two boxes. It shows pretty clearly that the abort trap problem in 2.6.x is my configuration problem. On the development box, I have mutliple Pythons, with varying degrees of IDLE success; on the production box I have only the factory installed 2.6.1 with no IDLE problem other than the one originally reported. Both boxes are under 10.6.4.

Development:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
$ /usr/bin/idle2.6
CGColor with 1 components
Abort trap
# This is probably due to paths crossed with 2.6.6
$ sudo /usr/bin/idle2.6
2010-10-20 10:12:16.329 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
2010-10-20 10:12:31.868 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
0
#IDLE works, otherwise, except for the segmentation issue

Production:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
#IDLE works, except for the segmentation issue

for completeness:

Development:
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
$ idle3
Floating point exception

Development:
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
** IDLE can't import Tkinter.  Your Python may not be configured for Tk. **

Development:
Python 2.6.6 (r266:84292, Aug 28 2010, 10:17:47) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
#IDLE hangs

According to Ronald (msg92914) and Ned (msg92923) this particular issue is 2.6 only (and fixed in 2.7 because of patches not backported).
2.6 is in security fix only mode.
So unless someone claims that this is a security issue (and Barry agrees) or reports that this particular issue appears in a current version (2.7.1, 3.1.3, 3.2) separate from other open Apple/Tk/IDLE issues, this should be closed.

Now that ActiveState has released a version of Tcl/Tk 8.5 (8.5.9.2) for Mac OS X that is also an Aqua Cocoa Tk (like the Apple-supplied Tk 8.5.7 in 10.6) and supports 64-bit, versions of Python linked with the new ActiveTcl 8.5.9 do not display the problem reported here as well as a number of other problems reported elsewhere.  Unfortunately, as released, the Apple-supplied Python 2.6.1 in 10.6 links only to the Apple-supplied Tcl/Tk 8.5.  Unless Apple releases an updated version of their Tcl/Tk 8.5, the best solution is to avoid using the IDLE 2.6 supplied with OS X 10.6.

There is now a webpage that summarizes the somewhat confusing state of affairs with regard to Tcl/Tk support with Python on Mac OS X.  While it is focused on Python installers downloadable from python.org, it does mention the Apple IDLE 2.6.1 problems:

http://www.python.org/download/mac/tcltk/