<div dir="ltr">On Wed, Oct 15, 2008 at 2:11 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><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 class="Ih2E3d">On Wed, Oct 15, 2008 at 11:03 AM, Terry Reedy <<a href="mailto:tjreedy@udel.edu">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>
</div>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).</blockquote><div><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>
<br>George<br></div></div><br></div>