Right. But such hooks would be sufficient to properly maintain the units attribute on a DataArray and check whether math made sense. This could use pint under the covers.

If you try to put a pint array into xarray.DataArray right now, I'm pretty sure it will get cast into a NumPy array.

At this point I'd be happy to have hooks that let me intercept/wrap ufunc operations, though I guess that's what #1938 is supporting in a more systematic way.

@dopplershift see https://github.com/pydata/xarray/issues/1938. Units should be able to make use of the same machinery as sparse arrays (__array_ufunc__ and multipledispatch), but xarray itself implementing __array_ufunc__ is not particularly useful, because you still can't put your own custom array types inside xarray objects.

This looks awesome. Thoughts on where you think units fits in here?

One potential edge case is if someone directly calls a ufunc reduce method, e.g., np.add.reduce. Previously, this would cast the xarray object to a numpy array, but now it will raise an error.

Example: ```

current xarray

In [3]: np.add.reduce(xr.DataArray([1])) Out[3]: 1

with this pull request

In [3]: np.add.reduce(xr.DataArray(0)) NotImplementedError: reduce method for ufunc <ufunc 'add'> is not implemented on xarray objects, which currently only support the call method. ```

Note that the more commonly used aliases for these reduce methods, e.g., np.sum() will continue to work since they check for sum() method on their argument.

There are also a few other ufunc methods that get used occasionally.

I think I'm OK breaking these because usage is so rare (and the work-around of casting to numpy arrays is so easy) but this should probably be noted in the release notes.