<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Sep 2, 2018 at 12:58 PM Charles R Harris <<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I propose to accept NEP-18, "A dispatch mechanism for NumPy’s high level array functions":<div><a href="http://www.numpy.org/neps/nep-0018-array-function-protocol.html" target="_blank">http://www.numpy.org/neps/nep-0018-array-function-protocol.html</a><br><div><br></div><div><div>Since the last round of discussion, we added a new section on "Callable objects generated at runtime" clarifying that to handle such objects is out of scope for the initial proposal in the NEP.</div><br>If there are no substantive objections within 7 days from this email, then the NEP will be accepted; see NEP 0 for more details.<br><br></div></div></div></blockquote><div><br></div><div>Skipping over all the discussion following this for brevity. I find myself in general agreement with Stephan and think we should go ahead and merge this. A few points:</div><div><ol><li>I don't think we should have an opt in environment variable, just put `__array_function__` out there with the understanding that it might change with experience. I don't think scores, let alone thousands, of folks are going to rush to take advantage of this, most likely the developers of the proposal will be the early adopters.</li><li>I have a preference for implementing high level functions rather than low level, and fewer rather than more, with the choice driven by need. I think that will limit the amount of interdependence tangle and, in the long run, might serve to define an unofficial NumPy API.<br></li><li>NumPy cannot manage all the projects that make use of the new option to keep them in sync, we have neither the time nor experience to do so, and historic attempts along those lines tended to die in obscurity. To the extent that we do so, it comes down to 2.</li><li>I don't think this conflicts with Nathaniel's proposal, the main disagreement seems to over how to proceed and the selection of functions, see 2.</li><li>The `__array_function_types__` idea looks interesting.</li></ol><div></div></div></div></div></blockquote><div><br></div><div>We might want to add an 'Experimental' status for NEPs, meaning accepted but subject to modification.</div><div><br></div><div>Chuck </div></div></div>