In the meantime I'll make a PR to get rid of it from SciPy. We can also signal other libraries to do so. Anything frees up the already-very-crowded namespace of NumPy dot is worth it in my opinion.
On Tue, Aug 28, 2018 at 7:40 PM Stephan Hoyer <sho...@gmail.com> wrote: > > > On Tue, Aug 28, 2018 at 9:03 AM Ralf Gommers <ralf.gomm...@gmail.com> > wrote: > >> 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. >> > > To be clear, I don't think np.ediff1d is particularly useful or necessary, > despite these uses. Most of these uses don't even use the optional > arguments, so the author was probably simply ignorant of np.diff. This is > more or less inevitable for most corners of NumPy's API, given how many > users we have. > > "PendingDeprecationWarning" is Python's built-in warning for signaling > that something is obsolete but not deprecated yet. It might be appropriate > to use in these cases. The default warning filters silence it for users, so > it doesn't show up unless you're very aggressive about enabling all > warnings. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
