[Guido]
And this is exactly why encodings will remain important: entities encoded in ISO-2022-JP have no compelling reason to be recoded permanently into ISO10646, and there are lots of forces that make it convenient to keep it encoded in ISO-2022-JP (like existing tools).
[Paul]
You cannot recode an ISO-2022-JP document into ISO10646 because 10646 is a character *set* and not an encoding. ISO-2022-JP says how you should represent characters in terms of bits and bytes. ISO10646 defines a mapping from integers to characters.
OK. I really meant recoding in UTF-8 -- I maintain that there are lots of forces that prevent recoding most ISO-2022-JP documents in UTF-8.
They are both important, but separate. I think that this automagical re-encoding conflates them.
Who is proposing any automagical re-encoding?
Are you sure you understand what we are arguing about?
*I* am not even sure what we are arguing about.
I am simply saying that 8-bit strings (literals or otherwise) in Python have always been able to contain encoded strings.
Earlier, you quoted some reference documentation that defines 8-bit strings as containing characters. That's taken out of context -- this was written in a time when there was (for most people anyway) no difference between characters and bytes, and I really meant bytes. There's plenty of use of 8-bit Python strings for non-character uses so your "proof" that 8-bit strings should contain "characters" according to your definition is invalid.
--Guido van Rossum (home page: http://www.python.org/%7Eguido/)