[Numpy-discussion] Revised NEP-18, __array_function__ protocol

[Stephan Hoyer]

On Tue, Jun 26, 2018 at 11:27 PM Hameer Abbasi <einstein.edison at gmail.com>
wrote:

> I would like to propose that we use `__array_function` in the following
> manner for functions that create arrays:
>
>    - `array_reference` for indicating the “reference array” whose
>    `__array_function__` implementation will be called. For example,
>    `np.arange(5, array_reference=some_dask_array)`.
>    - I use a reference in the design rather than a type because for some
>    arrays (such as Dask), chunk sizes or other reference data is needed to
>    make this work.
>
>
> I realise that this is a big design decision, so I welcome any input!
>

These are somewhat similar to the existing ones_like, zeros_like and
full_like.

My inclination would be to consider adding new functions/methods for these
rather than a new argument, e.g., arange_like() and random_like(), which
could then use the standard __array_function__ dispatching mechanism. But
this is pretty orthogonal to the design of __array_function__ either way,
so I think we could safely defer this to another NEP (which could be pretty
short!).

One concern this does raise is how to handle methods like those on
RandomState, even though methods like random_like() don't currently exist.
Distribution objects from scipy.stats could have similar use cases.

So perhaps it's worth "future proofing" the interface by passing `obj` and
`method` to __array_function__ rather than only `func`. It is slower to
call a func via func.__call__ than func, but only very marginally (~100 ns
in my tests).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180627/bb7a8174/attachment.html>