On Tue, Aug 28, 2018 at 8:04 AM Charles R Harris <charlesr.har...@gmail.com> wrote:
> > > On Mon, Aug 27, 2018 at 8:05 PM Stephan Hoyer <sho...@gmail.com> wrote: > >> On Mon, Aug 27, 2018 at 10:30 AM Tyler Reddy <tyler.je.re...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
