On 15. Aug 2018, at 18:25, Matthew Brett <matthew.brett@gmail.com> wrote:Hi,

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 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@python.org

https://mail.python.org/mailman/listinfo/numpy-discussion

Best Regards,

Hameer Abbasi

Hameer Abbasi