deprecation of product, cumproduct, alltrue, sometrue functions
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. Cheers, Ralf
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. - Sebastian
Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
On Mon, Mar 6, 2023 at 8:12 AM Sebastian Berg <sebastian@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. Cheers, Ralf
- Sebastian
Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ralf.gommers@gmail.com
On Tue, 2023-03-07 at 12:17 +0000, Ralf Gommers wrote:
On Mon, Mar 6, 2023 at 8:12 AM Sebastian Berg < sebastian@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... - Sebastian
Cheers, Ralf
- Sebastian
Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: ralf.gommers@gmail.com
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
On Tue, Mar 7, 2023 at 1:02 PM Sebastian Berg <sebastian@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 < sebastian@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
participants (2)
-
Ralf Gommers -
Sebastian Berg