Rich Comparisons Gotcha
robert.kern at gmail.com
Mon Dec 8 00:04:08 EST 2008
James Stroud wrote:
> Robert Kern wrote:
>> James Stroud wrote:
>>> I'm missing how a.all() solves the problem Rasmus describes, namely
>>> that the order of a python *list* affects the results of containment
>>> tests by numpy.array. E.g. "y in ll1" and "y in ll2" evaluate to
>>> different results in his example. It still seems like a bug in numpy
>>> to me, even if too much other stuff is broken if you fix it (in which
>>> case it apparently becomes an "issue").
>> It's an issue, if anything, not a bug. There is no consistent
>> implementation of bool(some_array) that works in all cases. numpy's
>> predecessor Numeric used to implement this as returning True if at
>> least one element was non-zero. This works well for bool(x!=y) (which
>> is equivalent to (x!=y).any()) but does not work well for bool(x==y)
>> (which should be (x==y).all()), but many people got confused and
>> thought that bool(x==y) worked. When we made numpy, we decided to
>> explicitly not allow bool(some_array) so that people will not write
>> buggy code like this again.
>> The deficiency is in the feature of rich comparisons, not numpy's
>> implementation of it. __eq__() is allowed to return non-booleans;
>> however, there are some parts of Python's implementation like
>> list.__contains__() that still expect the return value of __eq__() to
>> be meaningfully cast to a boolean.
> You have explained
> py> 112 = [1, y]
> py> y in 112
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ValueError: The truth value of an array with more than one element is...
> but not
> py> ll1 = [y,1]
> py> y in ll1
> It's this discrepancy that seems like a bug, not that a ValueError is
> raised in the former case, which is perfectly reasonable to me.
Nothing to do with numpy. list.__contains__() checks for identity with "is"
before it goes to __eq__().
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Python-list