Hi, On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson <andyf...@gmail.com> wrote: > > On Mon, 9 Oct 2023 at 20:34, <norbertpiotraduc...@gmail.com> wrote: >> >> Surely you can do this for all functions of eg.nan*. Why separate them is >> the only thing that distinguishes them. Setting the parameter seems to be >> more handy and user-friendly. Well for me it's seems better to do it right >> away in NumPy 2.0 > > > I think I prefer the clearer intent of having nan* functions.
Could you say more about why you consider: np.mean(x, dropna=True) to be less clear in intent than: np.nanmean(x) ? Is it just that someone could accidentally forget that the default for `np.mean` is not to drop NaNs? If so - is that a major problem? We would be introducing `dropna=True` as not-default, on a world that is used to the default. I must say I have several times found myself thinking - why is there a separate function for means when dropping NaN? Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
