[Numpy-discussion] Possible Deprecation of np.ediff1d (original) (raw)
Ralf Gommers ralf.gommers at gmail.com
Tue Aug 28 12:03:24 EDT 2018
- Previous message (by thread): [Numpy-discussion] Possible Deprecation of np.ediff1d
- Next message (by thread): [Numpy-discussion] Possible Deprecation of np.ediff1d
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Aug 28, 2018 at 8:04 AM Charles R Harris <charlesr.harris at gmail.com> wrote:
On Mon, Aug 27, 2018 at 8:05 PM Stephan Hoyer <shoyer at gmail.com> wrote: On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy <tyler.je.reddy at gmail.com> wrote:
Chuck suggested ( https://github.com/numpy/numpy/pull/11805#issuecomment-416069436 ) that we may want to consider deprecating np.ediff1d, which is perhaps not much more useful than np.diff, apart from having some arguably strange prepend / append behavior added in.
Related discussion on SO: https://stackoverflow.com/questions/39014324/difference-between-numpy-ediff1d-and-diff Thoughts? Best wishes, Tyler
I don't think there's much to be gained by dropping edit1d from NumPy. It's really not a maintenance burden to keep it around unchanged. My preference, in keeping with our tradition of not unnecessarily causing disruption, would be to keep this function around but mention that np.diff should be preferred for almost all use cases in the docs. This is "Official discouragement" strategy that came up in the recent discussion about our deprecation policy: https://mail.python.org/pipermail/numpy-discussion/2018-July/078474.html I did a search in Google's codebase and turned up only a handful of uses (~20 uses total) but in a variety of different projects: - It appears in astropy, dask, pandas, pint, scipy and TensorFlow. - It used in six different internal projects Maybe we need a "NumpyObsoleteWarning" :) At the least, we should probably have a list of obsolete functions in the documentation somewhere. My main concern is that as we go forward we might end up supporting a bunch of functions that are seldom used and have better replacements. We need some method of pruning.
Given the list of uses Stephan turned up and Robert saying it's a useful function, I'm -1 on any warning. If np.diff gets the same padding behavior, we can document ediff1d in its document as being superceded with a recommendation to use np.diff instead.
In such a docstring warning we could include an easily searchable phrase that we start using for all such functions, but I don't think there's much value in that.
Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180828/6c449366/attachment.html>
- Previous message (by thread): [Numpy-discussion] Possible Deprecation of np.ediff1d
- Next message (by thread): [Numpy-discussion] Possible Deprecation of np.ediff1d
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]