Python 3 __cmp__ semantic change?

[Duncan Booth]

Johannes Bauer <dfnsonfsduifb at gmx.de> wrote:

> Seems it was removed on purpose - I'm sure there was a good reason for
> that, but may I ask why? Instead of the sleek __cmp__ function I had
> earlier, I now have code like:
> 
> 
> def __lt__(self, other):
>      return self.__cmp__(other) < 0
>      
> def __le__(self, other):
>      return self.__cmp__(other) < 0

I hope you actually have <= here.

>      
> def __gt__(self, other):
>      return self.__cmp__(other) > 0
> 
> def __ge__(self, other):
>      return self.__cmp__(other) >= 0
> 
> Does anyone know the reason why __cmp__ was discarded?

I think it was because __cmp__ was the backward compatible fallback for 
the newer rich comparison methods and Python 3 cleans up a lot of stuff 
left in just for backward compatibility. In this case it is a cleanup 
too far as in most cases (i.e. those cases where you don't need the full 
complexity of the rich comparisons) __cmp__ is a much simpler solution.

See http://mail.python.org/pipermail/python-dev/2003-March/034073.html 
for Guido's original thoughts. Also, once upon a time pep-3000 referred 
to the removal of __cmp__ but I can't find it in any of the current 
peps. See
http://mail.python.org/pipermail/python-checkins/2004-August/042959.html
and
http://mail.python.org/pipermail/python-checkins/2004-August/042972.html
where the reference to removal of __cmp__ became "Comparisons other than 
``==`` and ``!=`` between disparate types will raise an exception unless 
explicitly supported by the type" and the reference to Guido's email 
about removing __cmp__ was also removed.


-- 
Duncan Booth http://kupuguy.blogspot.com