Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The reason we are prepared to make an exception for Unicode is precisely
> because the code point maps to an encoding pattern independently of
> architecture, ISTM.
Right --- there is a well-defined standard for the numerical value of
each character in Unicode. And it's also clear what to do in
single-byte encodings. It's not at all clear what the representation
ought to be for other multibyte encodings. A direct transliteration
of the byte sequence not only has endianness issues, but will have
a weird non-dense set of valid values because of the restrictions on
valid multibyte characters.
Given that chr() has never before behaved sanely for multibyte values at
all, extending it to Unicode code points is a reasonable extension,
and throwing error for other encodings is reasonable too. If we ever do
come across code-point standards for other encodings we can adopt 'em at
that time.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
