Quoting Rasmus Fogh <[EMAIL PROTECTED]>: > 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 -- http://mail.python.org/mailman/listinfo/python-list
