On Wednesday 10 December 2008 02:44:45 pm you wrote: > > Even in statically typed languages, when you override the equality > > operator/function you can choose not to return a valid answer (raise an > > exception). And it would break all the cases mentioned above (element in > > list, etc). But that isn't the right thing to do. The language > > doesn't/can't prohibit you from breaking the equality test, but that > > shouldn't be considered a feature. (a==b).all() makes no sense. > > Perhaps not in your application, but it does make sense in other > numeric applications, e.g. ones that work on vectors or matrixes. > > I'd suggest you simply wrap the comparison in a function and then > have that apply the necessary conversion to a boolean.
I do numeric work... I'm finishing my MSc in applied math and I'm programing mostly with python. And I'd rather have a.compare_with(b), or a.elementwise_compare(b), or whatever name, rather than (a==b).all(). In fact, I'd very much like to have an a.compare_with(b, epsilon=e).all() (to account for rounding errors), and with python2.5, all(a.compare_with(b)). Yes, I could create an element_compare(a,b) function. But I still can't use a==b and have a meaningful result. Ok, I can (and do) ignore that, it's just one library, I'll keep track of the types before asking for equality (already an ugly thing to do in python), but the a==b behaviour breaks the lists (a in ll, ll.indexof(a)) even for elements not in numpy. ¿Should I also ignore lists? The concept of equality between two arrays is very well defined, as it is also very well defined the element-by-element comparison. There is a need to test for both - then the way to test for equality should be the equality test. > > I'm certain that something could be worked out. A quick paragraph that > > took me just a few minutes to type shouldn't be construed as a PEP that > > will solve all the problems :D. > > As always: the Devil is in the details :-) Of course... -- Luis Zarrabeitia (aka Kyrie) Fac. de Matemática y Computación, UH. http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
