[Numpy-discussion] Extent to which to work around matrix and other duck/subclass limitations

[Marten van Kerkwijk]

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.gommers at gmail.com> wrote:

>
>
> On Fri, Jun 14, 2019 at 2:21 AM Marten van Kerkwijk <
> m.h.vankerkwijk at 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 at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190614/06b98872/attachment.html>