issue_comments: 788870926

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/pull/4979#issuecomment-788870926 https://api.github.com/repos/pydata/xarray/issues/4979 788870926 MDEyOklzc3VlQ29tbWVudDc4ODg3MDkyNg== 4160723 2021-03-02T12:23:41Z 2021-03-02T12:23:41Z MEMBER

One thing I'm missing is duckarray support, though. Not sure if this is realistic, but I'm hoping to reduce the maintenance burden on duckarray support libraries (such as pint-xarray) as much as possible: subclassing every new index class (or having the index provider explicitly add duckarray support) seems a bit too much work.

I haven't looked much at pint-xarray yet, so I'm not sure to understand. Why would you need to subclass every new index class?

If you are referring to the issue that you describe in your comment https://github.com/pydata/xarray/issues/525#issuecomment-514805244, the refactoring should decouple indexes from the coordinates, leaving the latter "just" as if they were regular variables (thus with duckarray support). What is currently possible with non-index coordinates should be possible with all coordinates. Actually, I'm not sure that we'll need to keep IndexVariable after the refactoring.

Or maybe you're referring to unit-aware indexing (what @shoyer mentioned in https://github.com/pydata/xarray/issues/525#issuecomment-514880353)? In this case I'm not sure how we could do that without having specific index classes for that purpose. Maybe some pre/post indexing hooks in Xarray that could be used, e.g., to convert indexer units into the coordinate units? 

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