One thing that should be pointed out is that there is a subtle difference between calling
`np.mean(x, where=~np.isnan(x))` and `np.nanmean(x)` Assuming totally normal numpy arrays, the former will first produce a boolean array of size N, then a second boolean array of size N to have the negated values. Meanwhile, no such extra arrays are made for the latter case. So, you are asking users to move to a potentially less performant alternative that will use more memory. At least, that used to be the case. I haven't checked to see if np.nanmean() has changed its implementation since the introducton of where= to ufuncs. Also, for another perspective, there is a point to be made about whether it is the data that should indicate what needs to be skipped, or should the algorithm dictate that? I can see pros and cons to both views. Code that changes behavior just because it was passed in an xarray.DataArray instead of a numpy array can be quite surprising. Downstream developers will be creating functions that combine several of these functions, and might need them to behave in a mix of ways. Making changes here would need a very compelling case to make things better across the board. In addition, functions like `np.nanmean()` were heavily inspired by matlab. While that isn't nearly as strong an argument for keeping it as it used to be 10 years ago, it does still mean something that users in other languages expect these functions to exist. Cheers! Ben Root On Thu, Oct 23, 2025 at 5:41 PM Carlos Martin <[email protected]> wrote: > > Another, perhaps more radical, possibility is to remove special handling for > nans from NumPy entirely. More precisely: > > 1. Add a `where` argument to all normal counterparts of nan-ignoring > functions that are currently missing it (see > https://github.com/numpy/numpy/issues/26336). > 2. Add a short FAQ entry to the docs instructing users to use > `where=~np.isnan(a)` to ignore nans. (Optional.) > 3. Add a deprecation warning to the nan-ignoring functions. > 4. Delete the nan-ignoring functions after an appropriate deprecation cycle. > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
