[Python-ideas] Automatic total ordering

[Terry Reedy]

Guido van Rossum wrote:
> On Wed, Oct 15, 2008 at 11:03 AM, Terry Reedy <tjreedy at udel.edu> 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