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/
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