# Rich Comparisons Gotcha

Luis Zarrabeitia kyrie at uh.cu
Wed Dec 10 23:21:51 CET 2008

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

```

More information about the Python-list mailing list