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/2773#issuecomment-565407674,https://api.github.com/repos/pydata/xarray/issues/2773,565407674,MDEyOklzc3VlQ29tbWVudDU2NTQwNzY3NA==,35968931,2019-12-13T11:27:26Z,2019-12-13T11:27:26Z,MEMBER,"I would love to see this.

What would we want the exact formatting to be? Square brackets to copy how units from `attrs['units']` are displayed on plots? e.g.
```
<xarray.Dataset>
Dimensions:  (time: 3, x: 988, y: 822)
Coordinates:
  * x [m]             (x)            float64 ...
  * y [m]             (y)            float64 ...
  * time [s]          (time)         datetime64[ns] ...
Data variables:
    rainfall [mm]     (time, y, x)   float32 ...
    max_temp [deg C]  (time, y, x)   float32 ...
```
The lack of vertical alignment is kind of ugly...

There are now two cases to discuss: units in `attrs`, and unit-aware arrays like pint. (If we do the latter we may not need the former though...)

from @keewis on #3616:

>At the moment, the formatting.diff_*_repr functions that provide the pretty-printing for assert_* use repr to format NEP-18 strings, truncating the result if it is too long. In the case of pint's quantities, this makes the pretty printing useless since only a few values are visible and the unit is in the truncated part.
>
> What should we about this? Does pint have to change its repr?

We could presumably just extract the units from pint's repr to display them separately. I don't know if that raises questions about generality of duck-typing arrays though @dcherian ? Is it fine to make units a special-case?","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,411365882