R
Robin Becker
I'm trying to understand what's going on with this simple program
if __name__=='__main__':
print("repr=%s" % repr(u'\xc1'))
print("%%r=%r" % u'\xc1')
On my windows XP box this fails miserably if run directly at a terminal
C:\tmp> \Python33\python.exe bang.py
Traceback (most recent call last):
File "bang.py", line 2, in <module>
print("repr=%s" % repr(u'\xc1'))
File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\xc1' in position 6:
character maps to <undefined>
If I run the program redirected into a file then no error occurs and the the
result looks like this
C:\tmp>cat fff
repr='â”´'
%r='â”´'
and if I run it into a pipe it works as though into a file.
It seems that repr thinks it can render u'\xc1' directly which is a problem
since print then seems to want to convert that to cp437 if directed into a terminal.
I find the idea that print knows what it's printing to a bit dangerous, but it's
the repr behaviour that strikes me as bad.
What is responsible for defining the repr function's 'printable' so that repr
would give me say an Ascii rendering?
-confused-ly yrs-
Robin Becker
if __name__=='__main__':
print("repr=%s" % repr(u'\xc1'))
print("%%r=%r" % u'\xc1')
On my windows XP box this fails miserably if run directly at a terminal
C:\tmp> \Python33\python.exe bang.py
Traceback (most recent call last):
File "bang.py", line 2, in <module>
print("repr=%s" % repr(u'\xc1'))
File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\xc1' in position 6:
character maps to <undefined>
If I run the program redirected into a file then no error occurs and the the
result looks like this
C:\tmp>cat fff
repr='â”´'
%r='â”´'
and if I run it into a pipe it works as though into a file.
It seems that repr thinks it can render u'\xc1' directly which is a problem
since print then seems to want to convert that to cp437 if directed into a terminal.
I find the idea that print knows what it's printing to a bit dangerous, but it's
the repr behaviour that strikes me as bad.
What is responsible for defining the repr function's 'printable' so that repr
would give me say an Ascii rendering?
-confused-ly yrs-
Robin Becker