On 15 Oct 2008, at 19:35, George Sakkis wrote:
On Wed, Oct 15, 2008 at 2:11 PM, 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).
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.
I don't understand. In a mathematical ordering, * x > y means the same as y < x * x <= y means the same as x < y or x = y * x >= y means the same as x > y or x = y and this is irrespective of whether the ordering is partial or total. So, given __eq__ and __lt__, all the rest follows. E.g. def __gt__(self, other): return other.__lt__(self) etc... Where am I going wrong? -- Arnaud