[Numpy-discussion] Adding to the non-dispatched implementation of NumPy methods

[Stephan Hoyer]

On Fri, Apr 26, 2019 at 1:24 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

> Thanks, this helped clarify what's going on here. This example is clear.
> The problem seems to be that there's two separate discussions in this
> thread:
> 1. your original proposal, __numpy_implementation__. it does not have the
> problem of your np.concatenate example, as the "numpy implementation" is
> exactly the same as it is today.
> 2. splitting up the current numpy implementation into *multiple* entry
> points. this can be with and without coercion, with and without checking
> for invalid values etc.
>
> So far NEP 18 does (1). Your proposed __numpy_implementation__ addition to
> NEP 18 is still (1). Claiming that this affects the situation with respect
> to backwards compatibility is incorrect.
>
> (2) is actually a much more invasive change, and one that does much more
> to increase the size of the NumPy API surface. And yes, affects our
> backwards compatibility situation as well.
>
> Also note that these have very different purposes:
> (1) was to (quoting from the NEP) "allow using NumPy as a high level API
> for efficient multi-dimensional array operations, even with array
> implementations that differ greatly from numpy.ndarray."
> (2) is for making duck arrays work with numpy implementations of functions
> (not just with the NumPy API)
>
> I think (1) is mostly achieved, and I'm +1 on your NEP addition for that.
> (2) is quickly becoming a mess, and I agree with Nathaniel's sentiment
> above "I shouldn't expect __array_function__ to be useful for duck
> arrays?". For (2) we really need to go back and have a well thought out
> design. Hameer's mention of uarray could be that. Growing more __array_*__
> protocols in a band-aid fashion seems unlikely to get us there.
>

Yes, very well put. I agree, let's try to keep focused on (1) for now.

(2) got brought up because of potential confusing about what
"__numpy_implementation__" means, but certainly we don't want to figure out
those issues now.

To that end, I'd love to hear more suggestions for naming what I
tentatively called "__numpy_implementation__". I suppose we could always go
for "__implementation_used_by_numpy_ndarray_array_function__" ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190426/7cf16390/attachment-0001.html>