Forgetting "()" when calling methods

[Tim Peters]

[Terry Reedy]
> ...
> At one time, it was easy for anyone to get 100% on a quiz like 'how
> many of the following lists can Python sort?".

OTOH, how many would have scored 100% if also asked what the result of
sorting would be?  I'm not sure anyone could have.  For years, ints came out
"less than" lists, which in turn came out "less than" longs, so that

    [10, [9], 7L, 8]

was considered to be "in sorted order" as-is.  It was something like 7 years
before someone finally noticed how nuts that was.

> Now, even some experienced users, might miss the correct answer for
> the following pair (0, 1, or 2?):
>
> [1, 1j].sort()
> ['1', 1j].sort()
>
> (For anyone who is not sure, make a guess and then cut&paste to fine
> out.)

It may be even more valuable for people who are certain <wink>.

> One bad turn does not deserve another.

I'm pretty sure that if Python had never supported meaningless (although
consistent within a single run) comparisons, a compelling case for adding
them couldn't have been made.  Mixed-type comparisons are usually
meaningless (which is less, an xrange object or math.sin?  The answer is
math.sin.  So how does math.sin compare to math.cos?  The answer is that's
not defined, but that you'll get the same result each time you compare those
two within a single program run).  When that's so, sorting brings objects of
the same type next to each other, and that's about it.  But if that's "the
use case" (if it isn't, what is the use case?!), it's much more efficient
(O(N) vs O(N log N)) to segregate objects via a dict mapping type to a list
of objects with that type.