> On 15. Aug 2018, at 18:25, Matthew Brett <matthew.br...@gmail.com> wrote: > > Hi, > > Thanks Nathaniel for this thoughtful response. > > On Mon, Aug 13, 2018 at 10:44 AM, Nathaniel Smith <n...@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@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > <https://mail.python.org/mailman/listinfo/numpy-discussion> Best Regards, Hameer Abbasi
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion