[issue13153] IDLE crash with unicode bigger than 0xFFFF

New submission from João Bernardo : I was playing with some unicode chars on Python 3.2 (x64 on Windows 7), but when pasted a char bigger than 0x, IDLE crashes without any error message. Example (works fine): >>> '\U000104a2' '𐒢' But, if I try to paste the above char, the window will insta

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ned Deily added the comment: This is related to Issue12342. The problem is that Tcl/Tk 8.5 (and earlier) do not support Unicode code points outside the BMP range as in this example. So IDLE will be unable to display such characters but it should not crash either. -- assignee: -> ne

[issue13153] IDLE crash with unicode bigger than 0xFFFF

João Bernardo added the comment: @Ned That looks like a bit different case. IDLE *can* print the char after you entered the '\U' version of it. It doesn't accept you to paste those caracters... -- ___ Python tracker

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Changes by Ezio Melotti : -- nosy: +ezio.melotti type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Terry J. Reedy added the comment: The current Windows build used 2-byte unicode chars because that is what Windows does. In 3.3, all builds will use a new unicode implementation that uses 1,2,or4 bytes as needed. But I suspect we will still have the paste problem unless we can somehow bypass

[issue13153] IDLE crash with unicode bigger than 0xFFFF

João Bernardo added the comment: Just for comparison, on Python 2.7.1 (x32 on Windows 7) it's possible to paste the char (but can't use it) and a nice error is given. >>> u'𐒢' Unsupported characters in input So the problem was partially solved but something might have happened with the 3.x

[issue13153] IDLE crash with unicode bigger than 0xFFFF

João Bernardo added the comment: Just to complete my monologue: Here's the traceback from running IDLE in cmd line. C:\Python32\Lib\idlelib>python -i idle.py Traceback (most recent call last): File "idle.py", line 11, in idlelib.PyShell.main() File "C:\Python32\Lib\idlelib\PyShell.py"

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Terry J. Reedy added the comment: [Yes, indexing will still be O(1), though I personally consider that less important than most make it to be. Consistency across platforms and total time and space performance of typical apps should be the concern. There is ongoing work on improving the new im

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ned Deily added the comment: Thanks for the additional investigation. You don't see more in the traceback because the exception is occurring in the _tkinter C glue layer. I am able to reproduce the problem on some other platforms as well (e.g. Python 3.x on OS X with Carbon Tk 8.4). More l

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ezio Melotti added the comment: > Ezio, do you know anything about these speculations? Assuming that the non-BMP character is represented with two surrogates (\ud801\udca2) and that _tkinter tries to decode them independently, the error message ("invalid continuation byte") would be correct.

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ezio Melotti added the comment: This can also be reproduced by doing: >>> print('\U000104a2'[0]) � and then copy/pasting the lone surrogate. The traceback is: [...] File "C:\Programs\Python32\Lib\tkinter\__init__.py", line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8'

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Terry J. Reedy added the comment: > I'm not sure what you mean with "turn them into bug reports" though. In about the last month, there have been, I think, 4 reports about IDLE crashing (quitting unexpectedly with no error traceback). I would consider it preferable if it quit with an error tr

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ezio Melotti added the comment: > I would consider it preferable if it quit Note that if we catch the error there might be no reason for IDLE to quit (unless the error left IDLE in some invalid state). > with an error traceback that gave as much info as available, That might scare newbies a

[issue13153] IDLE crash with unicode bigger than 0xFFFF

Ned Deily added the comment: Just to be sure we're talking about the same thing here, my understanding is that the "missing traceback" issues referred to here are only an issue when IDLE is run as a stand-alone GUI program, such as can be done on Windows and with the OS X IDLE.app. In that c