On Tue, Oct 10, 2023 at 6:32 PM Matthew Brett <matthew.br...@gmail.com> wrote:
> 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. > > > > ... > > > > 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 > > Keep in mind that the dropna argument might very well be on a different line (especially with black formatting), so searches could be much harder than looking for the nanmean function. (I do not deal with enough NaN data to have a strong view either way here) Peter
_______________________________________________ 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
