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

[Ralf Gommers]

On Tue, Apr 23, 2019 at 4:31 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi All,
>
> Reading the discussion again, I've gotten somewhat unsure that it is
> helpful to formalize a way to call an implementation that we can and
> hopefully will change. Why not just leave it at __wrapped__? I think the
> name is no worse and it is more obvious that one relies on something
> private.
>

I'm not convinced about the name either. NEP 18 also suggests adopting the
protocol in other libraries, so for SciPy would we have to name it
__scipy_implementation__? Not sure that's better or worse than a generic
__wrapped__

I don't see why the numpy implementation must be considered private though.
It's public today, and there's little wrong with keeping it public. The "it
can change" doesn't really apply, it has the same backwards compat
guarantees going forward that we have now.


> I ask in part since I could see a good case for having a special method
> that is available only for functions that do no explicit casting to array,
> i.e., that are ready to accept array mimics (and for which we're willing to
> guarantee that would not change). For instance, functions like np.sinc that
> really have no business using more than ufuncs under the hood, i.e., which
> any class that has __array_ufunc__ can call safely. Or (eventually) all
> those functions that just end up calling `concatenate` - those again could
> easily be made safe for a class that just overrides `np.concatenate` using
> __array_function__. In essence, this would be any function that does not do
> `np.as(any)array` but just relies on array attributes.
>
> But the above obviously presumes a vision of where this is headed, which
> I'm not sure is shared...
>

This is an orthogonal topic I think - you want multiple implementations,
"safe" and "unsafe" (or fast vs checking for invalids vs robust for
subclasses, etc. - lots of options here).

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190423/b1d8d887/attachment.html>