<div dir="ltr">On Wed, Oct 15, 2008 at 4:50 PM, Arnaud Delobelle <span dir="ltr"><<a href="mailto:arnodel@googlemail.com">arnodel@googlemail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
On 15 Oct 2008, at 19:35, George Sakkis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Oct 15, 2008 at 2:11 PM, Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> wrote:<br>
<br>
On Wed, Oct 15, 2008 at 11:03 AM, Terry Reedy <<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>> wrote:<br>
> George Sakkis wrote:<br>
>><br>
>> Now that 3.x fixes the arbitrary object comparison wart and drops (?)<br>
>> __cmp__,<br>
><br>
> An entry for __cmp__ was in the 3.0c1 doc, which confused me.<br>
> It is now gone in<br>
> <a href="http://docs.python.org/dev/3.0/reference/datamodel.html#special-method-names" target="_blank">http://docs.python.org/dev/3.0/reference/datamodel.html#special-method-names</a><br>
><br>
> Since rich comparisons are defined on object and are inherited by all<br>
> classes, it would be difficult to make them not defined.<br>
<br>
I should also note that part of George's proposal has already been<br>
implemented: if you define __eq__, you get a complementary __ne__ for<br>
free. However it doesn't work the other way around (defining __ne__<br>
doesn't give you __eq__ for free), and there is no similar<br>
relationship for the ordering operators. The reason for the freebie is<br>
that it's *extremely* unlikely to want to define != as something other<br>
than the complement of == (the only use case is IEEE compliant NaNs);<br>
however it's pretty common to define non-total orderings (e.g. set<br>
inclusion).<br>
<br>
Partial orderings are certainly used, but I believe they are far less common than total ones. Regardless, a partially ordered class has to explicitly define the supported methods with the desired semantics anyway; the proposed change wouldn't make this any harder.<br>

</blockquote>
<br></div></div>
I don't understand.  In a mathematical ordering,<br>
<br>
* x > y means the same as y < x<br>
* x <= y means the same as x < y or x = y<br>
* x >= y means the same as x > y or x = y<br>
<br>
and this is irrespective of whether the ordering is partial or total.<br>
<br>
So, given __eq__ and __lt__, all the rest follows. E.g.<br>
<br>
def __gt__(self, other):<br>
    return other.__lt__(self)<br>
etc...<br>
<br>
Where am I going wrong?</blockquote><div><br>For total orderings, one can define all methods in terms of self.__eq__ and self.__lt__, i.e. avoid making any assumption about `other`, e.g:<br><br>
def __gt__(self, other):<br>
    return not (self == other or self < other)<br><br>Your __gt__ definition (which is also what Michael Foord does in his class decorator) may break mysteriously:<br><br>    class Thing(object):
<br>        def __init__(self, val):
<br>            self.val = val
<br> <br>    @total_ordering
<br>    class Thing_lt(Thing):
<br>        def __lt__(self, other):
<br>            return self.val < other.val
<br> <br>    >>> t1 = Thing_lt(1)
<br>    >>> t2 = Thing(2) <br>    >>>  t1 < t2<br>    True<br>
    >>>  t1 > t2<br>    ...<br>    RuntimeError: maximum recursion depth exceeded<br><br><br>George</div></div></div>