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

Hameer Abbasi einstein.edison at gmail.com
Thu Jun 28 08:46:02 EDT 2018


I think the usefulness of this feature is actually needed. Consider
`np.random.RandomState`. If we were to add what I proposed, the two could
work very nicely to (for example) do things like creating Dask random
arrays, from RandomState objects.

For reproducibility, Dask could generate multiple RandomState objects with
a seed sequential in the job numbers.

Looping in Matt Rocklin for this — He might have some input about the
design.

Best Regards,
Hameer Abbasi
Sent from Astro <https://www.helloastro.com> for Mac

On 28. Jun 2018 at 14:37, Marten van Kerkwijk <m.h.vankerkwijk at gmail.com>
wrote:




On Wed, Jun 27, 2018 at 3:50 PM, Stephan Hoyer <shoyer at gmail.com> wrote:


<snip>


> 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).
>

That would make it more similar yet to `__array_ufunc__`, but I'm not sure
how useful it is, as you cannot generically assume the methods have the
same arguments and hence they need their own dispatcher. Once you're there
you might as well pass them on directly (since any callable can be used as
the function). Indeed, for `__array_ufunc__`, this might not have been a
bad idea either...

-- Marten

_______________________________________________
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/20180628/513f5f52/attachment.html>


More information about the NumPy-Discussion mailing list