On Fri, Jun 14, 2019 at 2:21 AM Marten van Kerkwijk < m.h.vankerkw...@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. > I share that worry to some extent (an ever-growing collection of protocols). To be fair, we knew that __array_function__ wasn't perfect, but I think Stephan did a really good job making the case for why it was necessary, and that we needed to get something in place in 6-12 months rather than spending years on a more polished/comprehensive design. Given those constraints, we seem to have made a good choice that has largely achieved its goals. I'm still not sure you got my main objection. So I'll try once more. We now have a design, imperfect but it exists and is documented (to some extent). Let's call it design A. Now you're wanting clarity on a policy on how to move from design A to design B. However, what B even is isn't spelled out, although we can derive rough outlines from mailing list threads like these (it involves better handling of subclasses, allowing reuse of implementation of numpy functions in terms of other numpy functions, etc.). The right way forward is: 1. describe what design B is 2. decide if that design is a good idea 3. then worry about implementation and a migration policy Something that's specific to all nan-functions is still way too specific, and doesn't justify skipping 1-2 and jumping straight to 3. I don't know how to express it any clearer than the above in email format. If it doesn't make sense to you, it'd be great to have a call to discuss in person. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
