Hi Ralf, Thanks for the clarification. I think in your terms the bottom line was that I thought we had a design B for the case where a function was really "just a ufunc". But the nanfunctions show that even if logically they are a ufunc (which admittedly uses another ufunc or two for `where`), it is tricky, certainly trickier than I thought. And this discussion has served to clarify that even for other "simpler" functions it can get similarly tricky.
Anyway, bottom line is that I think you are right in actually needed a more proper discussion/design about how to move forward. All the best, Marten p.s. And, yes, `__array_function__` is quite wonderful! On Fri, Jun 14, 2019 at 3:46 AM Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > > 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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
