[Numpy-discussion] Proposal to accept NEP-18, __array_function__ protocol

Hameer Abbasi einstein.edison at gmail.com
Wed Aug 15 12:36:53 EDT 2018


> On 15. Aug 2018, at 18:25, Matthew Brett <matthew.brett at gmail.com> wrote:
> 
> Hi,
> 
> Thanks Nathaniel for this thoughtful response.
> 
> On Mon, Aug 13, 2018 at 10:44 AM, Nathaniel Smith <njs at pobox.com> wrote:
> ...
>> The other approach would be to incrementally add clean, well-defined
>> dunder methods like __array_ufunc__, __array_concatenate__, etc. This
>> way we end up putting some thought into each interface, making sure
>> that it's something we can support, protecting downstream libraries
>> from unnecessary complexity (e.g. they can implement
>> __array_concatenate__ instead of hstack, vstack, row_stack,
>> column_stack, ...), or avoiding adding new APIs entirely (e.g., by
>> converting existing functions into ufuncs so __array_ufunc__ starts
>> automagically working). And in the end we get a clean list of dunder
>> methods that new array container implementations have to define. It's
>> plausible to imagine a generic test suite for array containers. (I
>> suspect that every library that tries to implement __array_function__
>> will end up with accidental behavioral differences, just because the
>> numpy API is so vast and contains so many corner cases.) So the
>> clean-well-defined-dunders approach has lots of upsides. The big
>> downside is that this is a much longer road to go down.
> 
> Does everyone agree that, if we had infinite time and resources, this
> would be the better solution?
> 

More resources means (given NumPy’s consensus system), more people have to agree on the overall design, so in my mind, it might even be slower.

> If we devoted all the resources of the current Numpy grant to taking
> this track, could we complete it in a reasonable time?

I somehow think just the design of all these different protocols, heck, even ironing all these different protocols out and ignoring implementation; would take an unreasonably long amount of time, as evidenced by this one NEP.

I’m more in favour of using this one rather conservatively: Perhaps a mailing list consensus before actually adding a function to __array_function__, making sure it won’t hinder too much progress.

I also differ with Nathaniel on one minor thing with his comparisons to Firefox, CPython, pytest and Sphinx: We’re not talking about monkey-patching NumPy internals, we’re just talking about monkey-patching the public API. Of course, this is still a cost and can still hinder development, but it’s definitely better than exposing all internals.

> 
> Cheers,
> 
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion <https://mail.python.org/mailman/listinfo/numpy-discussion>


Best Regards,
Hameer Abbasi



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180815/f2fd0d85/attachment.html>


More information about the NumPy-Discussion mailing list