Annoying behaviour of the != operator

[Rocco Moretti]

Dan Sommers wrote:
> 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".
> 
>>>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.

The "wackyness" I refered to wasn't that a list of complex numbers isn't 
sortable, but the inconsistent behaviour of list sorting. As you 
mentioned, an arbitraty collection of objects in a list is sortable, but 
as soon as you throw a complex number in there, you get an exception.

One way to handle that is to refuse to sort anything that doesn't have a 
"natural" order. But as I understand it, Guido decided that being able 
to sort arbitrary lists is a feature, not a bug. But you can't sort ones 
with complex numbers in them, because you also want '1+3j<3+1j' to raise 
an error.

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

What "conflict"? Where are you getting the doesn't/can't/shouldn't 
prescription from?

Which method you use depends on what you want to achieve:

(Hypothetical Scheme)
Object Identity? - use 'is'
Mathematical Ordering? - use '__eq__' & friends
Object Equivalence? - use '__equiv__'
Arbitrary Ordering? (e.g. for list sorting) - use '__order__'

The only caveat is to define sensible defaults for the cases where one 
fuction is not defined. But that shouldn't be too hard.

__eqiv__ -> __eq__ -> is
__order__ -> __lt__/__cmp__

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

Except if you want the situation where "[1+2j, 3+4j].sort()" works, and 
'1+3j < 3+1j' fails.


I think the issue is you thinking along the lines of Mathematical 
numbers, where the four different comparisons colapse to one. Object 
identity? There is only one 'two' - heck, in pure mathematics, there 
isn't even a 'float two'/'int two' difference. Equivalence *is* 
mathematical equality, and the "arbitrary ordering" is easily defined as 
"true" ordering. It's only when you break away from mathematics do you 
see the divergance in behavior.