Annoying behaviour of the != operator

[Dan Sommers]

On Thu, 09 Jun 2005 15:50:42 +1200,
Greg Ewing <greg at cosc.canterbury.ac.nz> wrote:

> Rocco Moretti wrote:
>> The main problem is that Python is trying to stick at least three
>> different concepts onto the same set of operators: equivalence (are
>> these two objects the same?), ordering (in a sorted list, which comes
>> first?), and mathematical "size".

> A possible compromise would be to add a new special method,
> such as __equal__, for use by == and != when there is no
> __eq__ or __ne__. Then there would be three clearly separated
> levels of comparison: (1) __cmp__ for ordering, (2) __equal__
> for equivalence, (3) __eq__ etc. for unrestricted semantics.

>> This gives the wacky world where
>> "[(1,2), (3,4)].sort()" works, whereas "[1+2j, 3+4j].sort()" doesn't.

Python inherits that wackiness directly from (often wacky) world of
Mathematics.

IMO, the true wackiness is that

    [ AssertionError, (vars, unicode), __name__, apply ].sort( )

"works," too.  Python refusing to sort my list of complex numbers is a
Good Thing.

> To solve that, I would suggest a fourth category of "arbitrary
> ordering", but that's probably Py3k material.

Four separate classes of __comparison__ methods in a language that
doesn't (and can't and shouldn't) preclude or warn about rules regarding
which methods "conflict" with which other methods?  I do not claim to be
an expert, but that doesn't seem very Pythonic to me.

AIUI, __cmp__ exists for backwards compatibility, and __eq__ and friends
are flexible enough to cover any possible comparison scheme.

Why make the rules, the documentation, and the implementation even more
"interesting" than they already are?

Regards,
Dan

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>