Python 3.0 crashes displaying Unicode at interactive prompt

[Mark Tolonen]

"John Machin" <sjmachin at lexicon.net> wrote in message 
news:a8cd683f-853d-4665-bee4-7a0bdb84181e at c36g2000prc.googlegroups.com...
> On Dec 14, 9:20 am, "Martin v. Löwis" <mar... at v.loewis.de> wrote:
> > >> This is intended behavior.
> >
> > > I see. That means that the behaviour in Python 1.6 to 2.6 (i.e.
> > > encoding the text using the repr() function (as then defined) was not
> > > intended behaviour?
> >
> > Sure.
>
> "Sure" as in "sure, it was not intended behaviour"?
>
> > This behavior has not changed. It still uses repr().
> >
> > Of course, the string type has changed in 3.0, and now uses a different
> > definition of repr.
>
> So was the above-reported non-crash consequence of the change of
> definition of repr intended?

It is intended.  I ran into your same issue and voiced a similar complaint, 
but Martin pointed out that users of other characters sets wanted to see the 
characters they were using.  If you were in China, would you rather see:

    IDLE 2.6.1
    >>> x=u'\u9876'
    >>> x
    u'\u9876'
    >>> x=u'顶'
    >>> x
    u'\u9876'

or:

    IDLE 3.0
    >>> x='\u9876'
    >>> x
    '顶'
    >>> x='顶'
    >>> x
    '顶'

On Asian consoles that support the required characters, 3.0 makes much more 
sense.  Your cp850 console or my cp437 console can't support the characters, 
so we get the encoding error.  I'm sure our Asian colleagues love it, but 
our encoding-challenged consoles now need:

>>> x='\u9876'
>>> print(ascii(x))
'\u9876'

It's not very convenient, and I've found it is easier to use IDLE (or any 
other IDE supporting UTF-8) rather than the console when dealing with 
characters outside what the console supports.

-Mark