Hi,
On Tue, 10 Oct 2023 at 00:55, Andrew Nelson <andyf...@gmail.com> wrote: > > > On Mon, 9 Oct 2023 at 23:50, Matthew Brett <matthew.br...@lis.ac.uk> wrote: >> >> Hi, >> >> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson <andyf...@gmail.com> wrote: >> 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 > > > The discussion isn't a deal breaker for me, I just wanted to put out a > different POV. > The name of the function encodes what it does. By putting them both in the > function name it's clear what the function does. > > nanmean -> deals with nan when calculating a mean. > > -vs- > > mean -> calculates a mean > | > ----> oh, it has dropna as a keyword argument, that's how you deal with nan. > > > Imagine that one has a large codebase and you have to find all the locations > where nans could affect a mean. There may be lots of prod, sum, etc, also > distributed within the codebase. You wouldn't want to search for `dropna` > because you get every function that handles a nan. If you search for nanmean > you only get the locations you want. So, is this the more or less the difference between: grep 'np\.nanmean' *.py and grep 'np\.mean(.*,\s*dropna\s*=\s*True' *.py ? 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
