[Python-ideas] Automatic total ordering

[Guido van Rossum]

On Wed, Oct 15, 2008 at 12:12 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> 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).

I think we've done as much as I am comfortable with doing *by default*
(i.e. when inheriting from object). The rest should be provided via
mix-ins. But even those mix-ins should wait until 3.1.

> 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.

There could be several different mix-ins that implement a total
ordering based on different basis pairs. (Or even a single basis
operation -- *in principle* all you need is a '<' operation.)

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