On Wed, Aug 15, 2018 at 10:25 AM, Matthew Brett <matthew.brett@gmail.com> wrote:

Thanks Nathaniel for this thoughtful response.

On Mon, Aug 13, 2018 at 10:44 AM, Nathaniel Smith <njs@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? 

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

I think it is further down the road than that. Determining a core set of functions would depend on feedback (need), as well be dependent on implementation details for other functions. I think a dependency list for common NumPy functions might be interesting.

That said, I don't think the current proposal is orthogonal to this. I don't expect every NumPy function to make call through this API, and we should probably try to limit, and list, the functions that implement the proposed mechanism.