__array_ufunc__ counting down to launch, T-24 hrs.
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, Just a note that the __array_ufunc__ PR is ready to merge. If you are interested, you can review here <https://github.com/numpy/numpy/pull/8247>. Chuck
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Mar 30, 2017 at 7:40 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
I want to get this in too, but 24 hours seems like a very short deadline for getting feedback on such a large and complex change? I'm pretty sure the ndarray.__array_ufunc__ code that was just added a few hours ago is wrong (see comments on the diff)... My main comment, also relevant to the kind of high-level discussion we tend to use the mailing list for: https://github.com/numpy/numpy/pull/8247#issuecomment-290616432 -n -- Nathaniel J. Smith -- https://vorpus.org
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi All, Following Nathaniel's request, I have made a PR that changes the original NEP to describe the current implementation. * PR at https://github.com/charris/numpy/pull/9 * Rendered relevant page at http://www.astro.utoronto.ca/~mhvk/numpy-doc/neps/ufunc-overrides.html It may still be somewhat short on detail, but should now give the rationale for what we want to implement. All the best, Marten
![](https://secure.gravatar.com/avatar/7857f26c1ef2e9bdbfa843f9087710f7.jpg?s=120&d=mm&r=g)
Thanks for linking to the updated NEP, I've been looking for a good overview of this discussion. Up until now I haven't wanted to wade through the extensive discussion on this topic. I'm curious, if I want to simultaneously support older Numpy versions as well as newer versions, will I be able to leave implementations of __array_wrap__ and __array_prepare__ defined alongside __array_ufunc__? Optimally in such a way that older numpy versions use __array_wrap__ and newer versions only use __array_ufunc__. There isn't discussion about this in the NEP, but does this also have impacts on non-ufunc numpy operations like concatenate, dot, norm, hstack, and others? We currently make use of wrappers around those functions in yt but unfortunately they have poor discoverability for users, it would be nice if NumPy could do the right thing with nearest subclasses. On Fri, Mar 31, 2017 at 12:04 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Nathan, That is a good point: Yes, one can leave __array_prepare__ and __array_wrap__ in place: only for ufuncs will they be ignored if __array_ufunc__ is present; __array_wrap__ in particular will still be used by quite a lot of other numpy functions (other use of __array_prepare__ is usually a mistake, but sadly does happen...). Anyway, with older versions of numpy, code should continue to work as it did. All the best, Marten p.s. It is also important to leave __array_prepare__ and __array_wrap__ in place for possible other classes that assume your class is wrapped that way... p.s.2 The same holds for __array_priority__
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Mar 30, 2017 at 7:40 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
I want to get this in too, but 24 hours seems like a very short deadline for getting feedback on such a large and complex change? I'm pretty sure the ndarray.__array_ufunc__ code that was just added a few hours ago is wrong (see comments on the diff)... My main comment, also relevant to the kind of high-level discussion we tend to use the mailing list for: https://github.com/numpy/numpy/pull/8247#issuecomment-290616432 -n -- Nathaniel J. Smith -- https://vorpus.org
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi All, Following Nathaniel's request, I have made a PR that changes the original NEP to describe the current implementation. * PR at https://github.com/charris/numpy/pull/9 * Rendered relevant page at http://www.astro.utoronto.ca/~mhvk/numpy-doc/neps/ufunc-overrides.html It may still be somewhat short on detail, but should now give the rationale for what we want to implement. All the best, Marten
![](https://secure.gravatar.com/avatar/7857f26c1ef2e9bdbfa843f9087710f7.jpg?s=120&d=mm&r=g)
Thanks for linking to the updated NEP, I've been looking for a good overview of this discussion. Up until now I haven't wanted to wade through the extensive discussion on this topic. I'm curious, if I want to simultaneously support older Numpy versions as well as newer versions, will I be able to leave implementations of __array_wrap__ and __array_prepare__ defined alongside __array_ufunc__? Optimally in such a way that older numpy versions use __array_wrap__ and newer versions only use __array_ufunc__. There isn't discussion about this in the NEP, but does this also have impacts on non-ufunc numpy operations like concatenate, dot, norm, hstack, and others? We currently make use of wrappers around those functions in yt but unfortunately they have poor discoverability for users, it would be nice if NumPy could do the right thing with nearest subclasses. On Fri, Mar 31, 2017 at 12:04 PM Marten van Kerkwijk < m.h.vankerkwijk@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Nathan, That is a good point: Yes, one can leave __array_prepare__ and __array_wrap__ in place: only for ufuncs will they be ignored if __array_ufunc__ is present; __array_wrap__ in particular will still be used by quite a lot of other numpy functions (other use of __array_prepare__ is usually a mistake, but sadly does happen...). Anyway, with older versions of numpy, code should continue to work as it did. All the best, Marten p.s. It is also important to leave __array_prepare__ and __array_wrap__ in place for possible other classes that assume your class is wrapped that way... p.s.2 The same holds for __array_priority__
participants (5)
-
Charles R Harris
-
Marten van Kerkwijk
-
Nathan Goldbaum
-
Nathaniel Smith
-
Stephan Hoyer