This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author JBernardo
Recipients JBernardo, ezio.melotti, ned.deily, terry.reedy
Date 2011-10-15.04:03:45
SpamBayes Score 1.11022e-16
Marked as misclassified No
Message-id <>
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 port...

Searching on both source codes, I can see the following block was commented on Python3.2 but not on Python2.7 (Maybe someone removed someone else's bug fix?) and an `assert` was added.

#--- Lines 605 to 613 of

assert isinstance(source, str)
#                       v-- on Python2.7 it is types.UnicodeType instead
#if isinstance(source, str):
#    from idlelib import IOBinding
#    try:
#        source = source.encode(IOBinding.encoding)
#    except UnicodeError:
#        self.tkconsole.resetoutput()
#        self.write("Unsupported characters in input\n")
#        return

I uncommented those lines, removed the `assert` and deleted __pycache__ for fresh bytecode but the error keeps happening.

This function `runsource()` is only called after the return key is pressed so the bug was introduced on another part of the program.

I'll search further but it's hard to do that without traceback of the error.

(Maybe `runit()` is the problem because it seems to build the line and call `runsource(line)`)

PS: @Terry Reedy
That looks nice to have different lengths for chars but what will be the impact on performance? Indexing will still be in constant time?
Date User Action Args
2011-10-15 04:03:46JBernardosetrecipients: + JBernardo, terry.reedy, ned.deily, ezio.melotti
2011-10-15 04:03:46JBernardosetmessageid: <>
2011-10-15 04:03:45JBernardolinkissue13153 messages
2011-10-15 04:03:45JBernardocreate