You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The str->Unicode change widened IDLE/batch discrepancy.
In python 2.x, bytes are printable.
>> for i in range(256): print i, chr(i)
works fine. In python 3, chr has become (the old) unichr, and whether a
unicode character is printable depends on the environment. In particular,
under my Windows XP, the equivalent
>> for i in range(256): print (i, chr(i))
will still work fine under IDLE, but will now crash with an
UnicodeEncodeError when run from the command line.
----------------
Unfortunately, I'm not sure what the right solution actually is, other than
a mention in the Whats New document.
I believe the 2.5 code was using a system page to print those characters, as
they often looked like letters rather than <control>. Copying that would
probably be the wrong solution.
Limiting IDLE would add consistency, but might be a lot of work for the
equivalent of a --pedantic flag.
PEP-3138 seems to be proposing a default stdout BackslashReplace, which may
at least help.
Whether or not that works in 3k depends on your console's encoding; your
program works just fine for me in Linux, with a UTF-8 console.
Python 2.5 was not using a "system page" (whatever that is); it was
sending the bytes to the terminal as-is, which then could interpret them
according to whatever encoding it choses to. Again, on a UTF-8 terminal,
sending individual bytes above 128 is meaningless, so the console had to
deal with it somehow.
I fail to see a Python problem in this report, so I'm closing it as
"works for me".
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: