<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 26, 2018 at 11:27 PM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com">einstein.edison@gmail.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I would like to propose that we use `__array_function` in the following manner for functions that create arrays:</div><div><ul style="font-style:normal;font-variant-caps:normal;font-weight:normal;font-stretch:normal;font-size:15px;line-height:17px;font-family:"Helvetica Neue";text-decoration:none;color:rgb(0,0,0);background-color:rgba(0,0,0,0)"><li>`array_reference` for indicating the “reference array” whose `__array_function__` implementation will be called. For example, `np.arange(5, array_reference=some_dask_array)`.</li><li>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.</li></ul><div><br></div></div><div>I realise that this is a big design decision, so I welcome any input!</div></div></blockquote><div><br></div><div>These are somewhat similar to the existing ones_like, zeros_like and full_like.</div><div><br></div><div>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!).</div><div><br></div><div>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.</div><div><br></div><div>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).</div></div></div>