[Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

Nathaniel Smith njs at pobox.com
Sun Sep 8 04:56:15 EDT 2019

On Sun, Sep 8, 2019 at 1:04 AM Hameer Abbasi <einstein.edison at gmail.com> wrote:
> On 08.09.19 09:53, Nathaniel Smith wrote:
>> OTOH, __array_function__ doesn't allow this kind of simplification: if
>> we were using __array_function__ for ufuncs, every library would have
>> to special-case every individual ufunc, which leads to dramatically
>> more work and more potential for bugs.
> But uarray does allow this kind of simplification. You would do the following inside a uarray backend:
> def __ua_function__(func, args, kwargs):
>     with ua.skip_backend(self_backend):
>         # Do code here, dispatches to everything but

You can dispatch to the underlying operation, sure, but you can't
implement a generic ufunc loop because you don't know that 'func' is
actually a bound ufunc method, or have any way to access the
underlying ufunc object. (E.g. consider the case where 'func' is
'np.add.reduce'.) The critical part of my example was that it's a new
ufunc that none of these libraries have ever heard of before.

Ufuncs have lot of consistent structure beyond what generic Python
callables have, and the whole point of __array_ufunc__ is that
implementors can rely on that structure. You get to work at a higher
level of abstraction.

A similar but simpler example would be the protocol we've sketched out
for concatenation: the idea would be to capture the core similarity
between np.concatenate/np.hstack/np.vstack/np.dstack/np.column_stack/np.row_stack/any
other variants, so that implementors only have to worry about the
higher-level concept of "concatenation" rather than the raw APIs of
all those individual functions.



Nathaniel J. Smith -- https://vorpus.org

More information about the NumPy-Discussion mailing list