[Numpy-discussion] Numpy 'None' comparison FutureWarning

[Nathaniel Smith]

On 22 Sep 2014 03:02, "Demitri Muna" <demitri.muna at gmail.com> wrote:
>
>
> On Sep 21, 2014, at 5:19 PM, Eric Firing <efiring at hawaii.edu> wrote:
>
>> I think what you are missing is that the standard Python idiom for this
>> use case is "if self._some_array is None:".  This will continue to work,
>> regardless of whether the object being checked is an ndarray or any
>> other Python object.
>
>
> That's an alternative, but I think it's a subtle distinction that will be
lost on many users. I still think that this is something that can easily
trip up many people; it's not clear from looking at the code that this is
the behavior; it's "hidden". At the very least, I strongly suggest that the
warning point this out, e.g.
>
> "FutureWarning: comparison to `None` will result in an elementwise object
comparison in the future; use  'value is None' as an alternative."

Making messages clearer is always welcome, and we devs aren't always in the
best position to do so because we're to close to the issues to see which
parts are confusing to outsiders - perhaps you'd like to submit a pull
request with this?

> Assume:
>
> a = np.array([1, 2, 3, 4])
> b = np.array([None, None, None, None])
>
> What is the result of "a == None"? Is it "np.array([False, False, False,
False])"?

After this change, yes.

> What about the second case? Is the result of "b == None" ->
np.array([True, True, True, True])?

Yes again.

(Notice that this is also a subtle and confusing point for many users - how
many people realize that if they want to get the latter result they have to
write np.equal(b, None)?)

> If so, then
>
> if (b == None):
>     ...
>
> will always evaluate to "True" if b is "None" or *any* Numpy array, and
that's clearly unexpected behavior.

No, that's not how numpy arrays interact with if statements. This is
independent of the handling of 'arr == None': 'if multi_element_array' is
always an error, because an if statement by definition requires a single
true/false decision (it can't execute both branches after all!), but a
multi-element array by definition contains multiple values that might have
contradictory truthiness.

Currently, 'b == x' returns an array in every situation *except* when x
happens to be 'None'. After this change, 'b == x' will *always* return an
array, so 'if b == x' will always raise an error.

>
> On Sep 21, 2014, at 9:30 PM, Benjamin Root <ben.root at ou.edu> wrote:
>
>> That being said, I do wonder about related situations where the lhs of
the equal sign might be an array, or it might be a None and you are
comparing against another numpy array. In those situations, you aren't
trying to compare against None, you are just checking if two objects are
equivalent.

Benjamin, can you give a more concrete example? Right now the *only* time
== on arrays checks for equivalence is when the object being compared
against is None, in which case == pretends to be 'is' because of this
mysterious special case. In every other case it does a broadcasted ==,
which is very different.

> Right. With this change, using "==" with numpy arrays now sometimes means
"are these equivalent" and other times "element-wise comparison".

Err, you have this backwards :-). Right now == means element-wise
comparison except in this one special case, where it doesn't. After the
change, it will mean element-wise comparison consistently in all cases.

> The potential for inadvertent bugs is far greater than what convenience
this redefinition of a very basic operator might offer. Any scenario where
>
> (a == b) != (b == a)
>
> is asking for trouble.

That would be unfortunate, yes, but fortunately it doesn't apply here :-).
'a == b' and 'b == a' currently always return the same thing, and there are
no plans to change this - we'll be changing what both of them mean at the
same time.

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140921/4c86ee0a/attachment.html>