[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

Roumen Petrov <[EMAIL PROTECTED]> added the comment: Thanks Martin for correction: yes not reserved - assigned. Jean-Michel, you test case is incorrect. You terminal is run in CP1252 where byte \x80 is shown as euro sing. But if you run terminal(if is possible in reported operating system) in IS

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > I don't know iso codeset that define characters in code range 0x80 0x9f. That's not true. In ISO-8859-1 (atleast, in the IANA charset), these characters are indeed assigned - for control functions. So the ISO-8859-1 byte \x80 corresponds t

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

Roumen Petrov <[EMAIL PROTECTED]> added the comment: I don't know iso codeset that define characters in code range 0x80 0x9f. This range is reserved for control symbols. The code of euro is 0xa4 in iso-8859-15. Also changes include symbols like 1/2, 3/4 and I forgot other differences. -

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: unicode('€', 'iso-8859-15') > u'\x80' unicode('€', 'iso-8859-1') #*** > u'\x80' > > It looks like iso-8859-1 behaves as iso-8859-15 (typo somewhere?) That's correct, and intentional. iso-8850-1 and iso-8859-15 are *indeed* the sam

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

STINNER Victor <[EMAIL PROTECTED]> added the comment: If you write "€" in the Python interpreter (Python2), you will get a *bytes* string encoded in your terminal charset. Example on Linux (utf-8): Python 2.5.1 (r251:54863, Jul 31 2008, 23:17:40) >>> '€' '\xe2\x82\xac' Use "u" prefix to get u

[issue3995] iso-xxx/cp1252 inconsistencies in Python 2.* not in 3.*

New submission from Jean-Michel Fauth <[EMAIL PROTECTED]>: XP SP2 fr_CH cp1252 I have always found, there are some inconsistencies in the Python <=2.5 serie regarding the char endodings, especially the iso-8859-1, cp1252, iso-8859-15 encodings. I do not know if this must be considered as a bug