<div dir="ltr"><div dir="ltr">On Sun, Apr 28, 2019 at 8:42 AM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com">m.h.vankerkwijk@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>In summary, I think the guarantees should be as follows:<br></div><div>1.If you call np.function and<br></div><div>  - do not define __array_function__, changes happen only via the usual cycle.</div><div>  - define __array_function__, you take responsibility for returning the result.</div><div>2. If you call np.function.__wrapped__ and<br></div><div>  - input only ndarray, changes happen only via the usual cycle;</div><div>  - input anything but ndarray, changes can happen in any release.</div></div></blockquote><div><br></div><div>The uses that I've seen so far (in CuPy and JAX), involve a handful of functions that are directly re-exported from NumPy, e.g., jax.numpy.array_repr is the exact same object as numpy.array_repr:</div><div><a href="https://github.com/cupy/cupy/blob/c3f1be602bf6951b007beaae644a5662f910048b/cupy/__init__.py#L341-L366">https://github.com/cupy/cupy/blob/c3f1be602bf6951b007beaae644a5662f910048b/cupy/__init__.py#L341-L366</a><br></div><div><a href="https://github.com/google/jax/blob/5edb23679f2605654949156da84e330205840695/jax/numpy/lax_numpy.py#L89-L132">https://github.com/google/jax/blob/5edb23679f2605654949156da84e330205840695/jax/numpy/lax_numpy.py#L89-L132</a> </div><div><br></div><div>I suspect this will be less common in the future if __array_function__ takes off, but for now it's convenient because users don't need to know exactly which functions have been reimplemented. They can just use "import jax.numpy as np" and everything works.</div><div><br></div><div>These libraries are indeed passing CuPy or JAX arrays into NumPy functions, which currently happen to have the desired behavior, thanks to accidental details about how NumPy currently supports duck-typing and/or coercions.</div><div><br></div><div>To this end, it would be really nice to have an alias that *is* guaranteed to work exactly as if __array_function__ didn't exist, and not only for numpy.ndarray arrays.</div><div><br></div><div>Ralf raises a good point about the name. We don't need to add this attribute for ufuncs and __array_ufunc__ yet, but</div><div>(1) we might want this in the future, just for consistency in the design of __array_function__ and __array_ufunc__, and</div><div>(2) we definitely don't want to rule out converting functions into ufunc.</div><div><br></div><div>So we might as well pick a name that works for both, e.g., __skip_array_overrides__ rather than __skip_array_function__. This would let us save our users a bit of pain by not requiring them to make changes like  np.where.__skip_array_function__ -> np.where.__skip_array_ufunc__.</div></div></div>