Is 0 > None?? (fwd) (fwd)

Lulu of the Lotus-Eaters mertz at gnosis.cx
Mon Sep 3 21:18:42 CEST 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