More rants on a bad sort

[Tim Peters]

[Lulu of the Lotus-Eaters]
> ,,,
> The sorting algorithm winds up only performing allowed comparisons in:
>
>     [u'x', 'x', chr(255)].sort()

That's so because u'x' <= 'x' and 'x' <= chr(255).  Note that it's
impossible to guess whether a given user would *consider* this to be a
sorted list, though, because without specifying the intended encoding it's
impossible to know which Unicode character(s) is(are) encoded by chr(255).
The decoded Unicode string corresponding to that may be <, ==, or > than
u'x'.

> Well... OK.  We have a similar story with complex numbers:
>
>     >>> '1' < 1, 1j < '1'
>     (0, 1)
>     >>> 1 < 1j
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     TypeError: cannot compare complex numbers using <, <=, >, >=
>
> Given all that, is it POSSIBLE to construct a list containing a string,
> int, and complex, that will not crash on a sort?  I don't know!

It isn't, but it's hard to guess why anyone would care <wink>.

> I couldn't find one--and I THINK the relative order of complex and strings
> precludes it... but actually proving this one way or another is
> decidedly non-obvious.

It can't happen because (conceptually; the implementation is slicker) the
list is first sorted by alphabetical order of type name, where in order to
prevent cases like

    10 < [9] < 8L < 10

the "type name" of each numeric type is artificially considered to be the
empty string.  So if the list has a complex, an int, and a string, the order
is first conceptually reduced to one of these two cases:

    int, complex, string
    complex, int, string

Then an attempt to compare the int and complex values will be made (they
tied on the "primary sort key" -- they both pretended to have "" as their
type name), and that will complain.

Now you can blame that on that Python complains in some senseless cases.  I
blame it on that Python doesn't complain in all senseless cases <wink>.