homepage

IDLE do not response and you have to force to quit when you type the bad combination ctrl-shift-5.
I find it on my macbook when i try do type a [ character and type the bad combination by mistake because the keyboard are not exactly the same as the iMac.

What version of OSX do you use? 
Do you have ActiveState TCL installed, and if so, which version?
Does 'Ctrl+Shift+5' insert a special character in the keyboard layout you use? 
BTW. I cannot reproduce this on my machine (OSX 10.8.2) with a recent snapshot of the 3.2 branch.

I used OSX 10.8.2 build 12C54 on both Macbookair and iMac
I have ActiveState TCL installed 8.5
Ctrl-shift-5 does not correspond to a special character on my keyboard layout.
But i discovered that this combination open a window called "tab width" in the IDLE shell and the crash appears then the combination is done in a script window of IDLE

Thanks for the additional information! I can now reproduce a hang using just Ctrl-5 on a US keyboard input method. Ctrl-5 is the default IDLE keyboard accelerator for the "Tabify Region" menu item under the "Format" menu cascade for an edit window. With any current Python (2.7.3, 3.2.3, or 3.3.0rc3) linked with Cocoa Tk 8.5, using the Ctrl-5 accelerator key causes the hang, requiring a force quit. Selecting the menu item with a mouse causes the "Tab Width" window to appear as expected. Ctrl-5 seems to work properly with Pythons linked with either Carbon Tk 8.4 or with X11 8.5. There is a similar hang behavior with Ctrl-6 "Untabify Region" using Cocoa Tk 8.5 as well. Attached is an excerpt from a hang dump when running with a debug framework build of 3.3 tip.

Interestingly enough it seems to hang while handling an import error, when I break executation and look at the stack trace I see (amongst others):
#5 0x00000001000b11f1 in import_all_from [inlined] () at /Users/ronald/Projects/python/rw/default/Python/ceval.c:4614
4614	 PyErr_SetString(PyExc_ImportError,
(gdb) l
4609	 PyErr_Clear();
4610	 dict = _PyObject_GetAttrId(v, &PyId___dict__);
4611	 if (dict == NULL) {
4612	 if (!PyErr_ExceptionMatches(PyExc_AttributeError))
4613	 return -1;
4614	 PyErr_SetString(PyExc_ImportError,
4615	 "from-import-* object has no __dict__ and no __all__");
4616	 return -1;
4617	 }
4618	 all = PyMapping_Keys(dict);
(gdb) 
This is with an optimized build, the debugger isn't as useful as I'd like and some information seem suspect (such as a frame object with an obviously invalid value for f_code.
This is probably a red herring, I haven't been able to reproduce this particular problem with a debug build.
In the production build I got a (non-functional) popup for entering some information, in the debug build I don't even get that and the proces hangs in CFRunLoopRunSpecific (called by Tk). And that's due to a call to "tkwait window ..." (aka the "wait_window" method from tkinter.Misc).
Debugging is slightly annoying because 'pyo' from the gdb macros works, but the printing a python stack trace does not.
The call is eventually traceable to calling simpledialog.askinteger in EditorWindow.tabify_region_event (through _asktabwidth) and is likely a bug where TkCocoa doesn't like callbacks into Tk from an event handler (IIRC we've had those before)
A quick hack to test this theorie is to redefine tabify_region_event:
 def tabify_region_event(self, event):
 self.after(200, lambda: self._tabify_region_event(event))
 def _tabify_region_event(self, event):
 # original method
This doesn't actually help, IDLE still hangs and my theory is likely wrong.
The easiest workaround is likely to give up for now and disable the ^5 and ^6 shortcuts (as well as ^3 and ^4 as those don't crash but don't do anything either, while the menu entries do work).
Annoyingly other commands in the format menu work just fine (CTRL-T, CMD-], CMD-[)
(all of this with the tip of the default branch and a freshly installed copy of ActiveTcl 8.5 on OSX 10.8)

Is this still current? Mark, any ideas on a fix for this one?

Just tried and it seemed to work ok for me. I'm guessing it'll be a particular Tk version. Noting the timeline on the original bug report and subsequent comments, that was right when Tk 8.5 switched from Carbon to Cocoa, so it was probably something that got shaken out in later versions.

I can no longer reproduce this either so I agree with Mark that it has most likely been fixed in later versions of Tk. If the problem can be reproduced with current Tk releases, please re-open.