"John Machin" <sjmac...@lexicon.net> wrote in message
news:a8cd683f-853d-4665-bee4-7a0bdb841...@c36g2000prc.googlegroups.com...
On Dec 14, 9:20 am, "Martin v. Löwis" <mar...@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
--
http://mail.python.org/mailman/listinfo/python-list
