Guido van Rossum wrote:
On Wed, Oct 15, 2008 at 11:03 AM, Terry Reedy
wrote: George Sakkis wrote:
Now that 3.x fixes the arbitrary object comparison wart and drops (?) __cmp__, An entry for __cmp__ was in the 3.0c1 doc, which confused me. It is now gone in http://docs.python.org/dev/3.0/reference/datamodel.html#special-method-names
Since rich comparisons are defined on object and are inherited by all classes, it would be difficult to make them not defined.
I should also note that part of George's proposal has already been implemented: if you define __eq__, you get a complementary __ne__ for free. However it doesn't work the other way around (defining __ne__ doesn't give you __eq__ for free), and there is no similar relationship for the ordering operators. The reason for the freebie is that it's *extremely* unlikely to want to define != as something other than the complement of == (the only use case is IEEE compliant NaNs); however it's pretty common to define non-total orderings (e.g. set inclusion).
You previously said "Sure, but let's aim for 3.1." However, I could interpret the above as saying that we have already done as much as is sensible (except for changing the docs). Or are you merely saying that any other freebies must make sure to respect the possibility of non-total orderings and not accidentally convert such into a (non-consistent) 'total' ordering? There are several possible basis pairs of defined operations. A specification must list which one(s) would work. Terry