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.

Title: batch/IDLE differ: print broken for chraracters>ascii
Type: behavior Stage:
Components: Documentation, Unicode Versions: Python 3.0
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: georg.brandl Nosy List: georg.brandl, jimjjewett, loewis
Priority: normal Keywords:

Created on 2008-06-01 23:12 by jimjjewett, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (2)
msg67617 - (view) Author: Jim Jewett (jimjjewett) Date: 2008-06-01 23:12
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.
msg67628 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-06-02 05:14
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".
Date User Action Args
2022-04-11 14:56:35adminsetgithub: 47275
2008-06-02 05:14:35loewissetstatus: open -> closed
nosy: + loewis
resolution: works for me
messages: + msg67628
2008-06-01 23:12:23jimjjewettcreate