Just to mention for visibility: Introducing a "nan" option and deprecating nan* functions was considered for 2.0 main namespace refactor but it was deemed large enough to be (hopefully) tackled in a separate story/project.
https://github.com/numpy/numpy/issues/24306#issuecomment-1660073584 (first bullet point on the list) On Mon, Oct 9, 2023 at 12:48 PM 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. > _______________________________________________ > 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: mso...@quansight.com >
_______________________________________________ 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
