On 22 Sep 2014 03:02, "Demitri Muna" email@example.com wrote:
On Sep 21, 2014, at 5:19 PM, Eric Firing firstname.lastname@example.org 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?
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,
After this change, yes.
What about the second case? Is the result of "b == None" ->
np.array([True, True, True, True])?
(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 email@example.com 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.