On Thu, Jun 13, 2019 at 6:21 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
Hi Ralf,
Thanks both for the reply and sharing the link. I recognize much (from both sides!).
<snip>
More importantly, I think we should not even consider *discussing* removing` __array_function__` from np.isposinf (or any similar one off situation) before there's a new bigger picture design. This is not about "deprecation is hard", this is about doing things with purpose rather than ad-hoc, as well as recognizing that lots of small changes are a major drain on our limited maintainer resources. About the latter issue I wrote a blog post recently, perhaps that clarifies the previous sentence a bit and gives some more insight in my perspective: https://rgommers.github.io/2019/06/the-cost-of-an-open-source-contribution/
Yes, I definitely did not mean to imply that a goal was to change just
`isposinf`, `sum`, or `nansum` (the goal of the PR that started this thread was to clean up the whole `nanfunctions` module). Rather, to use them as examples to see what policy there actually is or should be; and I do worry that with __array_function__, however happy I am that it now exists (finally, Quantity can be concatenated!), we're going the Microsoft route of just layering on top of old code if even for the simplest cases there is no obvious path for how to remove it.
Anyway, this discussion is probably gotten beyond the point where much is added. I'll close the `nansum` PR.
All the best,
Marten
p.s. I would say that deprecations within numpy currently *are* hard. E.g., the rate at which we add `DEPRECATED` to the C code is substantially larger than that with which we actually remove any long-deprecated behaviour.
That's been true for the last couple of releases, but not historically. The main problem was lack of time compounded by a FutureWarning that got stuck because it broke code in unexpected ways when brought to fruition. For 1.16 I decided that expiring spent deprecations wasn't worth the churn. At this point I see 1.18 as the release that starts the cleanup, and possibly the start of removing the Python 2.7 compatibility code. Speaking of 1.18, the other thing I'd like to see is discussion of a masked array replacement. I think the basic infrastructure is now in place for that. Hmm... should probably make a separate post eliciting ideas for 1.18. Chuck