[MAL, on Unicode chr() and ord()
... Because unichr() will always have to return Unicode objects. You don't want chr(i) to return Unicode for i>255 and strings for i<256.
OTOH, ord() could probably be extended to also work on Unicode objects.
Fine. So I'll drop the uniord() API and extend ord() instead.
Hmm, then wouldn't it be more logical to drop unichr() too, but add an optional parameter to chr() to specify what sort of a string you want? The type-object of a unicode string comes to mind... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
Jack Jansen wrote:
[MAL, on Unicode chr() and ord()
... Because unichr() will always have to return Unicode objects. You don't want chr(i) to return Unicode for i>255 and strings for i<256.
OTOH, ord() could probably be extended to also work on Unicode objects.
Fine. So I'll drop the uniord() API and extend ord() instead.
Hmm, then wouldn't it be more logical to drop unichr() too, but add an optional parameter to chr() to specify what sort of a string you want? The type-object of a unicode string comes to mind...
Like: import types uc = chr(12,types.UnicodeType) ... looks overly complicated, IMHO. uc = unichr(12) and u = unicode('abc') look pretty intuitive to me. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 50 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (2)
-
Jack Jansen
-
M.-A. Lemburg