Is 0 > None?? (fwd) (fwd)
Lulu of the Lotus-Eaters
mertz at gnosis.cx
Mon Sep 3 15:18:42 EDT 2001
"Alex Martelli" <aleax at aleax.it> wrote:
> >>> u'ciaó'<'ciaó'
> Traceback (innermost last):
> File "<interactive input>", line 1, in ?
> UnicodeError: ASCII decoding error: ordinal not in range(128)
|Well, yes -- though the problem is not with the Unicode strings
|(as I've shown, you can perfectly well compare them to anything:-)
|The issue, it seems to me, is quite different wrt complex
|numbers -- in that case, there is _no_ setting that lets you
|default-sort an heterogeneous list that may contain a complex
|number somewhere. The Unicode issue might be finessed in
|several ways. The complex-number one is starker IMHO.
I don't understand the differenence Alex points to. For example, the
below cases seem awfully similar:
>>> # Try to sort Unicode values in list
>>> lst = [ 128, chr(128), unichr(128), 'a' ]
>>> lst
[128, '\x80', u'\x80', 'a']
>>> lst.sort()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
UnicodeError: ASCII decoding error: ordinal not in range(128)
>>> # Try to sort complex numbers in list
>>> l2 = [ 1, 1.0, 1+1j ]
>>> l2
[1, 1.0, (1+1j)]
>>> l2.sort()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: cannot compare complex numbers using <, <=, >, >=
What can I do to get 'lst' to sort properly? If the answer is to use a
custom comparison function, I can do likewise with complex numbers. I
suppose one could say the problem was with the 'chr(128)' element rather
than the 'unichr(128)' element... but such a characterization doesn't
particularly bring a solution closer.
Yours, Lulu...
P.S. The thing that could be fixed in a later Python is the
non-universal comparison... we are stuck with 'print >>' for backwards
compatibility.
More information about the Python-list
mailing list