Forgetting "()" when calling methods

[Tim Peters]

[Tim]
>> 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.

[Alex Martelli]
> *Blink* -- I don't get it.  Even if int < list < long, how CAN the
> two int's here be ``considered in sorted order''???

They weren't, it was the list itself that was considered to be in sorted
order, because checking for sorted order doesn't compare every pair of
elements (if it did, sorting would be best-case quadratic time), it only
compares adjacent pairs, and

    10 < [9] < 7L < 8

Comparison wasn't always transitive.  Python eventually wormed around that,
by internally pretending that all "numeric types" have a type name
consisting of an empty string for purposes of comparing an object of numeric
type to one of non-numeric type.  That hack forces objects of numeric types
next to each other, and then their inter-numeric-type coercions can come
into play.  That's as much of a hack as it sounds, and it only works
reliably for builtin numeric types (where Python knows for sure to pretend
the type name is an empty string).

For the rest, I'm out of time.  Briefly:  If pretty printing a dict is the
killer use case, then that could surely be addressed by writing a dict
pretty-printing routine that didn't rely on meaningless comparison results.

> ...
> What's the ADVANTAGE gained, worth breaking prettyprinting for?

A language in which

    100 < "2"

is true has got at least one deep problem.  If it goes on to claim

    math.sin < xrange(10)

too, its view of comparisons is simply bizarre, and *on the face of it*.  I
believe this is a case where absurd behavior is defended simply because some
highly experienced Python programmers "got used to it".  Newbies who point
out that if Python doesn't let them add a string to an int, it shouldn't
allow comparing them either, make more sense to me.

> It seems to me it's basically one of "purity"

More that errors shoudn't pass silently.  1.5.2 took a wholly pure view.