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-677698531,https://api.github.com/repos/pydata/xarray/issues/4324,677698531,MDEyOklzc3VlQ29tbWVudDY3NzY5ODUzMQ==,3460034,2020-08-20T14:25:39Z,2020-08-20T14:25:39Z,CONTRIBUTOR,"> I brought this up at the meeting, and if I remember correctly, the recommendation was to take a step back and solve nested duck arrays in general (e.g. by writing a design doc – a NEP?). Correct me if I'm wrong, @shoyer, but I think the hope was that after that it would be easier to design nested reprs.

Sounds good! Would it make sense to discuss that over on https://github.com/dask/dask/issues/5329, the pre-existing issue for this larger problem of nested duck array reprs/meta?

Also, since `_repr_inline_` is already implemented, I'd still like to see a basic version of https://github.com/xarray-contrib/pint-xarray/pull/22 merged in, so at least we have good results in the ""easy"" case of xarray > Pint > NumPy.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,675342733
https://github.com/pydata/xarray/issues/4324#issuecomment-672077055,https://api.github.com/repos/pydata/xarray/issues/4324,672077055,MDEyOklzc3VlQ29tbWVudDY3MjA3NzA1NQ==,3460034,2020-08-11T16:36:17Z,2020-08-11T16:36:17Z,CONTRIBUTOR,"@benbovy These are some good suggestions about possible final products to aim towards in the implementation. Unfortunately, there are a couple problems to keep in mind:

- The main impetus for custom inline text reprs was [including units in the dataset overview](https://github.com/pydata/xarray/issues/2773), and so, that functionality needs to be kept available. Having a very compact description representing the duck array type would be insufficient.
- Inspecting the full order of general nested duck arrays is non-trivial. Right now, every duck array that acts as a wrapper/container has its own way of referencing what it contains and combining its own reprs with what it contains. The simplest way for this to work (and how it works now) is to trust that each array layer is handling the next one below it properly without any information of the other layers beyond that. https://github.com/dask/dask/issues/5329 proposed establishing some shared way of organizing/managing all this nested duck array metadata, which almost certainly would be needed for anything more complex/robust.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,675342733