Is 0 > None?? (fwd) (fwd)
paul at svensson.org
Tue Sep 4 18:22:51 CEST 2001
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
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.
More information about the Python-list