Rich Comparisons Gotcha

[Luis Zarrabeitia]

Quoting Rasmus Fogh <rhf22 at mole.bio.cam.ac.uk>:
> Rhamphoryncus wrote:
> > You grossly overvalue using the "in" operator on lists.
> 
> Maybe. But there is more to it than just 'in'. If you do:
> >>> c = numpy.zeros((2,))
> >>> ll = [1, c, 3.]
> then the following all throw errors:
> 3 in ll, 3 not in ll, ll.index(3), ll.count(3), ll.remove(3)
> c in ll, c not in ll, ll.index(c), ll.count(c), ll.remove(c)
> 
> Note how the presence of c in the list makes it behave wrong for 3 as
> well.

I think I lost the first messages on this thread, but... Wouldn't be easier to
just fix numpy? I see no need to have the == return anything but a boolean, at
least on Numpy's case. The syntax 'a == b' is an equality test, not a detailed
summary of why they may be different, and (a==b).all() makes no little sense to
read unless you know beforehad that a and b are numpy arrays. When I'm comparing
normal objects, I do not expect (nor should I) the == operator to return an
attribute-by-attribute summary of what was equal and what wasn't.

Why is numpy's == overloaded in such a counter intuitive way? I realize that an
elementwise comparison makes a lot of sense, but it could have been done instead
with a.compare_with(b) (or even better, a.compare_with(b, epsilon=e)). No
unexpected breakage, and you have the chance of specifying when you consider two
elements to be equal - very useful. 

Even the transition itself could be done without breaking much code... Make the
== op return an object that wraps the array of bools (instead of the array
itself), give it the any() and all() methods, and make __nonzero__/__bool__
equivalent to all().

-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie