On Tue, Jun 26, 2018 at 11:27 PM Hameer Abbasi <einstein.edi...@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).
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
