Finally got off my butt and hunted down an example, and it was right under my nose in mplot3d.
lib/python2.7/site-packages/mpl_toolkits/mplot3d/axes3d.py:1094: FutureWarning: comparison to `None` will result in an elementwise object comparison in the future. if self.button_pressed in self._rotate_btn: self._rotate_btn is the 1d numpy array, and self.button_pressed usually will have an integer (for which mouse button), but could be None if no mouse button was pressed. I have no clue why the "in" operator is triggering this future warning. Is this intentional? Ben Root On Sun, Sep 21, 2014 at 10:53 PM, Nathaniel Smith <n...@pobox.com> wrote: > On 22 Sep 2014 03:02, "Demitri Muna" <demitri.m...@gmail.com> wrote: > > > > > > On Sep 21, 2014, at 5:19 PM, Eric Firing <efir...@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.r...@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 > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
