html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/525#issuecomment-763119626,https://api.github.com/repos/pydata/xarray/issues/525,763119626,MDEyOklzc3VlQ29tbWVudDc2MzExOTYyNg==,14808389,2021-01-19T20:33:47Z,2021-01-26T00:16:46Z,MEMBER,"> 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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,100295585
https://github.com/pydata/xarray/issues/525#issuecomment-733754394,https://api.github.com/repos/pydata/xarray/issues/525,733754394,MDEyOklzc3VlQ29tbWVudDczMzc1NDM5NA==,14808389,2020-11-25T14:52:58Z,2020-11-25T16:07:57Z,MEMBER,"> 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](https://xarray.pydata.org/en/latest/internals.html#integrating-with-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`](https://github.com/dask/dask/issues/6385#issuecomment-656176799), though).
For reference, the currently remaining issues for all duck arrays (except obviously `dask`) are documented [here](https://xarray.pydata.org/en/latest/duckarrays.html)","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,100295585
https://github.com/pydata/xarray/issues/525#issuecomment-562966170,https://api.github.com/repos/pydata/xarray/issues/525,562966170,MDEyOklzc3VlQ29tbWVudDU2Mjk2NjE3MA==,14808389,2019-12-08T16:25:58Z,2019-12-08T23:24:23Z,MEMBER,"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?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,100295585
https://github.com/pydata/xarray/issues/525#issuecomment-514805244,https://api.github.com/repos/pydata/xarray/issues/525,514805244,MDEyOklzc3VlQ29tbWVudDUxNDgwNTI0NA==,14808389,2019-07-24T21:22:33Z,2019-07-24T21:22:33Z,MEMBER,"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`](https://github.com/pandas-dev/pandas/blob/3b96ada3a17f5fcc8c32a238457075ec4dd8433a/pandas/core/indexes/base.py#L166), 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
```
However, that branch is a quick hack, and I would suspect that supporting duck arrays has a similar effect.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,100295585