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

[Paul Svensson]

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> writes:

>Tue, 4 Sep 2001 10:01:02 +0200, Alex Martelli <aleax at aleax.it> 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.

Actually, it does, if you just don't insist on converting things.
Of course, this would have some not-quite-intuitive consequences,
like 'A' != u'A' or 1 != 1+0j.

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

Another argument for having (at least) two different ways of comparing things.

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

Exactly, but how much currently working code would it kill ?
Time to start planning for the __future__ ?

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

And it still misses the problem of when you have data that you cannot convert.

	/Paul