<html dir="ltr"><head></head><body style="text-align:left; direction:ltr;"><div>On Wed, 2019-05-22 at 08:52 -0700, Stephan Hoyer wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr">Thanks for raising these concerns.<div><br></div><div>The full implications of my recent __skip_array_function__ proposal are only now becoming evident to me now, looking at it's use in GH-13585. Guaranteeing that it does not expand NumPy's API surface seems hard to achieve without pervasive use of __skip_array_function__ internally.</div><div><br></div><div>Taking a step back, the sort of minor hacks [1] that motivated __skip_array_function__ for me are annoying, but really not too bad -- they are a small amount of additional code duplication in a proposal that already requires a large amount of code duplication.</div><div><br></div><div>So let's roll back the recent NEP change adding __skip_array_function__ to the public interface [2]. Inside the few NumPy functions where __array_function__ causes a measurable performance impact due to repeated calls (most notably np.block, for which some benchmarks are 25% slower), we can make use of the private __wrapped__ attribute.</div><div><br></div><div>I would still like to turn on __array_function__ in NumPy 1.17. At least, let's try that for the release candidate and see how it goes. The "all in" nature of __array_function__ without __skip_array_function__ will both limit its use to cases where it is strongly motivated, and also limits the API implications for NumPy. There is still plenty of room for expanding the protocol, but it's really hard to see what is necessary (and prudent!) without actual use.</div></div></blockquote><div><br></div><div>Agreed that we should turn it on for 1.17  RC, and see if there are any complaints.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>[1] e.g., see <a href="https://github.com/google/jax/blob/62473351643cecb6c248a50601af163646ba7be6/jax/numpy/lax_numpy.py#L2440-L2459">https://github.com/google/jax/blob/62473351643cecb6c248a50601af163646ba7be6/jax/numpy/lax_numpy.py#L2440-L2459</a><br></div><div>[2] <a href="https://github.com/numpy/numpy/pull/13305">https://github.com/numpy/numpy/pull/13305</a></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2019 at 11:44 PM Juan Nunez-Iglesias <<a href="mailto:jni.soma@gmail.com">jni.soma@gmail.com</a>> wrote:<br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><u></u><div><div>I just want to express my general support for Marten's concerns. As an "interested observer", I've been meaning to give `__array_function__` a try but haven't had the chance yet. So from my anecdotal experience I expect that more people need to play with this before setting the API in stone.<br></div><div><br></div><div>At scikit-image we place a very strong emphasis on code simplicity and readability, so I also share Marten's concerns about code getting too complex. My impression reading the NEP was "whoa, this is hard, I'm glad smarter people than me are working on this, I'm sure it'll get simpler in time". But I haven't seen the simplicity materialise...<br></div><div><br></div><div>On Wed, 22 May 2019, at 11:31 AM, Marten van Kerkwijk wrote:<br></div><blockquote type="cite" id="gmail-m_8025869066898200115qt" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div>Hi All,<br></div><div><br></div><div>For 1.17, there has been a big effort, especially by Stephan, to make __array_function__ sufficiently usable that it can be exposed. I think this is great, and still like the idea very much, but its impact on the numpy code base has gotten so big in the most recent PR (gh-13585) that I wonder if we shouldn't reconsider the approach, and at least for 1.17 stick with the status quo. Since that seems to be a bigger question than can be usefully addressed in the PR, I thought I would raise it here.<br></div><div><br></div><div>Specifically, now not only does every numpy function have its dispatcher function, but also internally all numpy function calls are being done via the new `__skip_array_function__` attribute, to avoid further overrides. I think both changes make the code significantly less readable, thus, e.g., making it even harder than it is already to attract new contributors.<br></div><div><br></div><div>I think with this it is probably time to step back and check whether the implementation is in fact the right one. For instance, among the alternatives we originally considered was one that had the overridable versions of functions in the regular `numpy` namespace, and the once that would not themselves check in a different one. Alternatively, for some of the benefits provided by `__skip_array_function__`, there was a different suggestion to have a special return value, of `NotImplementedButCoercible`. Might these be better after all?<br></div><div><br></div><div>More generally, I think we're suffering from the fact that several of us seem to have rather different final goals in mind  In particular, I'd like to move to a state where as much of the code as possible makes use of the simplest possible implementation, with only a few true base functions, so that all but those simplest functions will generally work on any type of array. Others, however, worry much more about making implementations (even more) part of the API.<br></div><div><br></div><div>All the best,<br></div><div><br></div><div>Marten<br></div></div><div>_______________________________________________<br></div><div>NumPy-Discussion mailing list<br></div><div><a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br></div><div><a href="https://mail.python.org/mailman/listinfo/numpy-discussion" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br></div><div><br></div></blockquote><div><br></div></div>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>
<pre>_______________________________________________</pre><pre>NumPy-Discussion mailing list</pre><a href="mailto:NumPy-Discussion@python.org"><pre>NumPy-Discussion@python.org</pre></a><pre><br></pre><a href="https://mail.python.org/mailman/listinfo/numpy-discussion"><pre>https://mail.python.org/mailman/listinfo/numpy-discussion</pre></a><pre><br></pre></blockquote></body></html>