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."
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])"?
What about the second case? Is the result of "b == None" -> np.array([True, True, True, True])? 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.
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.
Right. With this change, using "==" with numpy arrays now sometimes means "are these equivalent" and other times "element-wise comparison". 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.
Department of Astronomy
An Ohio State Universityhttp://trillianverse.orghttp://scicoder.org