> > [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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4