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

Marcin 'Qrczak' Kowalczyk qrczak at
Tue Sep 4 14:05:37 CEST 2001

Tue, 4 Sep 2001 10:01:02 +0200, Alex Martelli <aleax at> pisze:

> Comparison issues, and sorting of heterogeneous lists in
> particular, ARE central to the new noncomparable behavior
> of complex numbers.  I see no solution to THAT one, save:
>     a. either drop the pretense that it makes sense to
>         compare heterogeneous entities, or
>     b. regress the change that makes it illegal to compare
>         complex numbers.

c. Have two kinds of comparison, homogeneous and heterogeneous.
This solves the complex numbers problem, but unfortunately not the
str <-> unicode problem.

The real problem is that if Unicode strings and byte strings are
treated like alternative representation of the same data (as numeric
types are), i.e. they compare equal if they represent the same text,
then there are two incompatible orders involved: lexicographically by
Unicode character values and byte values. It would break transitiveness
of comparisons.

Actually it does break it if something othar than ASCII or Latin1 is
chosen as the default encoding!

    'Á' > 'Ą'
    'Á'.decode('iso-8859-2') < u'\u00D1' < 'Ą'.decode('iso-8859-2')
    'Á' < u'\u00D1' < 'Ą'   # when 'iso-8859-2' is the default

Since byte strings and Unicode strings can't be reliably compared
anyway, a solution would be to drop their equivalence, treat as
separate types, let 'A' != u'A', require explicit coercions in either
direction for homogeneous comparisons.

Alternatively comparison could consistently use the Unicode ordering -
but it's unworkable in practice, even with a sane default (not ASCII).
Byte strings are supposed to be able to represent binary data as well,
and it's inefficient.

 __("<  Marcin Kowalczyk * qrczak at
  ^^                      SYGNATURA ZASTĘPCZA

More information about the Python-list mailing list