Calling the ufunc in __array_wrap__ is probably a bad idea

[eric-wieser]

Since by that point, the ufunc has already run once. Although putting it in __array_prepare__ may also not solve the problem, since that:

__array_prepare__ should not attempt to access the array data or resize the array, it is intended for setting the output array type, updating attributes and metadata, and performing any checks based on the input that may be desired before computation begins.

[hgrecco]

I agree but there is no other way, as far as I now. I discuss this in the past with the numpy devs but there was no big interest to do provide a way to circunvent it. Recently the has been a discussion to add a new way to do this. It is still unstable.

[eric-wieser]

Here's a possible workaround:

• __array_prepare__:
  • check unit compatibility, raising exceptions if needed
  • convert arguments in args in-place to the same units (using .ito, perhaps). Store the old units and magnitudes
• __array_wrap__
  • restore the magnitude/units of args back to what they were

Yes, this violates the "attempt[ing] to access array data" rule, but calling the ufunc within __array_wrap__ is probably not really allowed either.

---

Could you link me to that discussion?

[hgrecco]

Take a look at numpy/numpy#4072

[eric-wieser]

Thanks, although that doesn't seem all that relevant to this discussion - the issue here is that you're not able to override ufunc behaviour at all, derivative of np.array or otherwise.

Also, there's some work in the numpy development pipeline to fix this with __numpy_ufunc__/__array_ufunc__ - presumably this is the discussion you were referring to?

What are your thoughts on my proposed workaround above?

[hgrecco]

Your workaround looks ok in theory. If you like, prototype it and we test it.

However, at the end the numpy devs need to provide a good way to do this.

By the way, have you seen #326 ?