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.vankerkw...@gmail.com> wrote: On Wed, Jun 27, 2018 at 3:50 PM, Stephan Hoyer <sho...@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@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
