Are there still concerns here? If not, I would love to move ahead with these changes so we can get this into NumPy 1.17.
On Tue, Apr 16, 2019 at 10:23 AM Stephan Hoyer <sho...@gmail.com> wrote: > __numpy_implementation__ is indeed simply a slot for third-parties to > access NumPy's implementation. It should be considered "NumPy's current > implementation", not "NumPy's implementation as of 1.14". Of course, in > practice these will remain very similar, because we are already very > conservative about how we change NumPy. > > I would love to have clean well-defined coercion semantics for every NumPy > function, which would be implicitly adopted by `__numpy_implementation__` > (e.g., we could say that every function always coerces its arguments with > `np.asarray()`). But I think that's an orthogonal issue. We have been > supporting some ad-hoc duck typing in NumPy for a long time (e.g., the > `.sum()` method which is called by `np.sum()`). Removing that would require > a deprecation cycle, which may indeed be warranted once we're sure we're > happy with __array_function__. But I don't think the deprecation cycle will > be any worse if the implementation is also exposed via > `__numpy_implementation__`. > > We should definitely still think about a cleaner "core" implementation of > NumPy functions in terms of a minimal core. One recent example of this can > be found JAX (see > https://github.com/google/jax/blob/04b45e4086249bad691a33438e8bb6fcf639d001/jax/numpy/lax_numpy.py). > This would be something appropriate to put into a more generic function > attribute on NumPy functions, perhaps `__array_implementation__`. But I > don't think formalizing `__numpy_implementation__` as a way to get access > to NumPy's default implementation will limit our future options here. > > Cheers, > Stephan > > > On Tue, Apr 16, 2019 at 6:44 AM Marten van Kerkwijk < > m.h.vankerkw...@gmail.com> wrote: > >> >> I somewhat share Nathaniel's worry that by providing >> `__numpy_implementation__` we essentially get stuck with the >> implementations we have currently, rather than having the hoped-for freedom >> to remove all the `np.asarray` coercion. In that respect, an advantage of >> using `_wrapped` is that it is clearly a private method, so anybody is >> automatically forewarned that this can change. >> >> In principle, ndarray.__array_function__ would be more logical, but as >> noted in the PR, the problem is that it is non-trivial for a regular >> __array_function__ implementation to coerce all the arguments to ndarray >> itself. >> >> Which suggests that perhaps what is missing is a general routine that >> does that, i.e., that re-uses the dispatcher. >> >> -- 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
