issue_comments

I would expect astropy quantities to work just fine as long as they are duck arrays

actually, that turns out to be wrong. Since isinstance(data, np.ndarray) returns true for astropy.units.Quantity, it is cast to ndarray using np.asarray: https://github.com/pydata/xarray/blob/7dbbdcafed7f796ab77039ff797bcd31d9185903/xarray/core/variable.py#L231-L245

Adding ~or issubclass(type(data), np.ndarray)~ or type(data) != np.ndarray does allow wrapping a astropy.units quantity in Dataset / DataArray objects ~but it breaks a few tests~. Also, unless we modify the testsuite in xarray/tests/test_units.py to run with astropy.units instead of pint I can't really tell which features of xarray strip the units (in addition to the ones documented for pint). For that, we probably need to somehow create a generalization of the tests for duck arrays.

I saw the discussion above about Quantities being more problematic

I would expect astropy quantities to work just fine as long as they are duck arrays. Also, the only limitation I would expect them to have is that they can't "wrap" anything other than numpy arrays. dask arrays are an exception since they can wrap quantities using the _meta attribute (which is something we try to avoid with pint, though).

For reference, the currently remaining issues for all duck arrays (except obviously dask) are documented here

sorry for the late reply, @ngoldbaum. For xarray to support unyt, it would have to implement NEP-18 (i.e. __array_function__) which I think it does not yet? I would expect to have unyt support come for free once pint support works so I would focus on that first (see #3594 for the current progress). Extending the tests to also test unyt would be possible but I'm thinking it would be better to put that into the accessor package (as discussed above for a possible pint accessor)?

There were a few unresolved design questions with how unit libraries should implement certain numpy functions (e.g. how where should behave when receiving array(nan) and array(0) which xarray uses to implement nanops, or which unit the result of full_like should have): see hgrecco/pint#905. Any supported unit library would have to behave the same way so I think it would be good to coordinate that. Thoughts?

In that branch I left it as xfail because I came to the conclusion that there was nothing I could do (directly at least): when creating a DataArray, the coords get * passed through as_variable(), which puts the coord array in Variable and for dimensions at least * calls Variable.to_index_variable(). In there the variable is converted to an IndexVariable and the array is * wrapped by PandasIndexAdapter where the array is * first passed through np.asarray (this would probably have to be removed/changed) and then to pandas.Index, which is where the units get stripped -- which can be verified by directly passing a unit array to it.

The units of coordinates that are not dimensions are not stripped: ```python

ureg = pint.UnitRegistry() v = np.arange(10 * 20).reshape(10, 20) * ureg.m / ureg.s d = np.arange(10) * ureg.m d2 = d.to(ureg.cm) t = np.arange(20) * ureg.s array = xr.DataArray(data=v, dims=('d', 't'), coords={'d': d, 'd2': ('d', d2), 't': t}) array.d.data array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]) array.d2.data <Quantity([ 0. 100. 200. 300. 400. 500. 600. 700. 800. 900.], 'centimeter')> ``` However, that branch is a quick hack, and I would suspect that supporting duck arrays has a similar effect.