[Numpy-discussion] __skip_array_function__ discussion summary

[Marten van Kerkwijk]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190523/30b78204/attachment.html>