[Python-3000] Need closure on __cmp__ removal

[Guido van Rossum]

On Jan 5, 2008 10:40 PM, hashcollision <hashcollision at gmail.com> wrote:
> David A. Wheeler has already written a draft PEP, which can be found here:
> http://www.dwheeler.com/misc/pep-cmp.txt.

Thanks, I'd missed that.

But alas, it's a bit short on the motivation for rich comparisons. For
example it fails to notice that quite a few object types need to be
comparable for equality but need not be orderable. Comparison for
equality only is often much faster than a full three-way-compare,
since there is likely some quick test that decides two instances
cannot possibly be equal (e.g. lists of different lengths). It also
misses the use case of overloading < and <= as set inclusion
operators.

But the biggest thing missing is precise semantics. Saying "exactly
the same semantics as with Python 2.5" doesn't cut it (those semantics
are incredibly hairy and sometimes surprising, and their
implementation was a nightmare -- I've rarely been as relieved as when
I was able to cut those out of the implementation).

A PEP should specify exactly what happens when both __cmp__ and one or
more of the __xx__ operators are defined on the same class; it should
specify what it means to override one or the other in a subclass; and
it should define Python and C APIs for invoking __cmp__ (and what it
should do if __cmp__ isn't defined).

I also notice that, because not-equal can often be decided more
quickly than a full ordering, the argument (which I brought up
myself!) that not having __cmp__ would slow down list comparisons may
be wrong or at least weak. E.g., for the sake of argument, let's
assume that __eq__ is just 10% faster than __cmp__, and __lt__ is as
fast as __eq__. Then comparing two lists using __cmp__ on successive
element pairs would be slower than using __eq__ plus one final __lt__
if the deciding element is beyond the 9th index. If __eq__ is twice as
fast as __cmp__ and __lt__ is the same speed as __cmp__, using __cmp__
would be slower beyond the 2nd index.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)