issue_comments: 672708892

This data as json

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/4324#issuecomment-672708892 https://api.github.com/repos/pydata/xarray/issues/4324 672708892 MDEyOklzc3VlQ29tbWVudDY3MjcwODg5Mg== 4160723 2020-08-12T08:01:32Z 2020-08-12T08:01:32Z MEMBER

Good points @jthielen.

Here's another suggestion:

  • Treat as two separate problems (1) inline display of duck array metadata and (2) inline preview of array values. This would let Xarray taking care of formatting the values (using format_array_flat, which won't need to be in public API), but this would require Xarray to know whether the duck array is lazy or not.

  • For inline display of duck array metadata, only show the _repr_inline_ of the top-layer (do not cascade _repr_inline_ of nested duck arrays). It's the responsibility of the top-layer library (e.g., Pint) to show metadata about the layers beyond.

  • Dask (duck) arrays (if they could be identified as-is https://github.com/dask/dask/issues/6385?) probably deserve their own treatment in the xarray variable repr too, because xarray exposes specific API for them (e.g., .compute()) and because we cannot trust that all duck array libraries will properly handle Dask duck arrays in their inline repr. I think that just a one-character symbol of some kind would be enough (similarly to * for coordinates with an index).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   675342733