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.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
