On Tue, Mar 7, 2023 at 1:02 PM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Tue, 2023-03-07 at 12:17 +0000, Ralf Gommers wrote: > > On Mon, Mar 6, 2023 at 8:12 AM Sebastian Berg < > > sebast...@sipsolutions.net> > > wrote: > > > > > On Thu, 2023-03-02 at 15:20 +0000, Ralf Gommers wrote: > > > > Hi all, > > > > > > > > In https://github.com/numpy/numpy/pull/23314 I am deprecating > > > > four > > > > functions: `product`, `cumproduct`, `alltrue`, `sometrue`. These > > > > are > > > > all > > > > aliases (for `prod`, `cumprod`, `all` and `any`), were already > > > > not > > > > part of > > > > the API docs, and there was an open issue for deprecating them ( > > > > https://github.com/numpy/numpy/issues/14584). > > > > > > > > The only one that may be slightly disruptive is `np.product`, > > > > there > > > > were a > > > > number of usages I found in other projects. Typically >10x less > > > > than > > > > `np.prod` and already cleaned up in SciPy, scikit-learn and > > > > pandas, > > > > but > > > > still a non-negligible amount. Hence pointing this one out in > > > > particular. > > > > > > > > > If there is larger chance of end-user churn/annoyance, we could > > > still > > > decide to take a it a bit slower by e.g. escalating to > > > `VisibleDeprecationWarning` before full removal. > > > > > > > Good point. Perhaps worth doing all in one go before the 1.25.0 > > release? > > Either all VisibleDeprecationWarning's, or for the functionality that > > we > > think may be used more often than the average deprecated function. > > > I guess do not care much about a 2.0 release finalizing deprecations > (neither do I mind here). > > I would probably not jump the normal deprecation (possibly except in a > 2.0 release). > The reason is that you have two "clients": > > 1. (Well maintained/tested) library authors need warning to update > their code. > This should happen without bothering users! That requires a normal > DeprecationWarning. > > 2. Less maintained libraries (and end-users): They may not see (or > care) about the DeprecationWarning, escalating to > VisibleDeprecationWarning might help them fix things up before they > suddenly break. > > That might buy a little bit of good-will by slightly smoothing the > transition... > Indeed. It probably makes sense to do that staggered - regular DeprecationWarning for one release, then checking back if the issue/PR gets referenced through links - if so, there's a good amount of users that had to adjust their code, which may warrant bumping to VisibleDeprecationWarning in the next release. I'll add this to the plan for the `np.product` one, and any future deprecations. Cheers, Ralf
_______________________________________________ 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
