Sebastian, Stefan and Marten -- thanks for the excellent summaries of the discussion.
In line with this consensus, I have drafted a revision of the NEP without __skip_array_function__: https://github.com/numpy/numpy/pull/13624 On Thu, May 23, 2019 at 5:28 PM Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi Sebastian, Stéfan, > > Thanks for the very good summaries! > > An additional item worth mentioning is that by using > `__skip_array_function__` everywhere inside, one minimizes the performance > penalty of checking for `__array_function__`. It would obviously be worth > trying to do that, but ideally in a way that is much less intrusive. > > Furthermore, it became clear that there were different pictures of the > final goal, with quite a bit of discussion about the relevant benefits of > trying the limit exposure of the internal API and of, conversely, trying to > (incrementally) move to implementations that are maximally re-usable (using > duck-typing), which are themselves based around a smaller core (more in > line with Nathaniel's NEP-22). > > In the latter respect, Stéfan's example is instructive. The real > implementation of `ones_like` is: > ``` > def ones_like(a, dtype=None, order='K', subok=True, shape=None): > res = empty_like(a, dtype=dtype, order=order, subok=subok, shape=shape) > multiarray.copyto(res, 1, casting='unsafe') > return res > ``` > > The first step is here seems obvious: an "empty_like" function would seem > to belong in the core. > The second step less so: Stéfan's `res.fill(1)` seems more logical, as > surely a class's method is the optimal way to do something. Though I do > feel `.fill` itself breaks "There should be one-- and preferably only one > --obvious way to do it." So, I'd want to replace it with `res[...] = 1`, so > that one relies on the more obvious `__setitem__`. (Note that all are > equally fast even now.) > > Of course, in this idealized future, there would be little reason to even > allow `ones_like` to be overridden with __array_function__... > > All the best, > > Marten > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
