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/5102#issuecomment-838055686,https://api.github.com/repos/pydata/xarray/issues/5102,838055686,MDEyOklzc3VlQ29tbWVudDgzODA1NTY4Ng==,4160723,2021-05-11T08:21:03Z,2021-05-11T08:21:03Z,MEMBER,All right let's merge this! Thanks everyone for your review comments.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490
https://github.com/pydata/xarray/pull/5102#issuecomment-836278394,https://api.github.com/repos/pydata/xarray/issues/5102,836278394,MDEyOklzc3VlQ29tbWVudDgzNjI3ODM5NA==,4160723,2021-05-10T07:12:36Z,2021-05-10T07:12:36Z,MEMBER,"Should we merge this?

In follow-up PRs, I plan to:

- Create a `PandasMultiIndex` class and refactor all places in Xarray that rely on `pd.MultiIndex` (internal changes only).
- Add public API to Xarray `Index` for label-based data selection and refactor/move the logic in `convert_label_indexer` into the Xarray `PandasIndex` and `PandasMultiIndex` classes.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490
https://github.com/pydata/xarray/pull/5102#issuecomment-831789860,https://api.github.com/repos/pydata/xarray/issues/5102,831789860,MDEyOklzc3VlQ29tbWVudDgzMTc4OTg2MA==,4160723,2021-05-04T09:01:10Z,2021-05-04T09:01:10Z,MEMBER,"Thanks for the review @shoyer, I addressed your comments.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490
https://github.com/pydata/xarray/pull/5102#issuecomment-830150205,https://api.github.com/repos/pydata/xarray/issues/5102,830150205,MDEyOklzc3VlQ29tbWVudDgzMDE1MDIwNQ==,4160723,2021-04-30T14:53:12Z,2021-04-30T14:53:12Z,MEMBER,"This is ready for review!

I implemented @shoyer's suggestions and finished updating the (many) places where Xarray directly uses pandas indexes.

I also added a `to_pandas_index()` method to the `Index` base class so that we can easily raise when an Xarray operation doesn't support flexible indexes (i.e., indexes that cannot be cast to a `pd.Index`).

There might still be some quick fixes that we could clean up now, but I think that most things will have to be cleaned up later in the refactoring once additional features/classes/etc. are implemented.

I haven't wrote tests for the `Index` base class yet as this is still very much preliminary work, I plan to do it in follow-up PRs once the API becomes more stable. 
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490
https://github.com/pydata/xarray/pull/5102#issuecomment-814034661,https://api.github.com/repos/pydata/xarray/issues/5102,814034661,MDEyOklzc3VlQ29tbWVudDgxNDAzNDY2MQ==,4160723,2021-04-06T11:09:38Z,2021-04-06T11:09:38Z,MEMBER,"Agreed for adding another property along with a couple of depreciation cycles for smooth transition on what is returned by `.indexes`. I've suggested `.index_adapters` in my previous comment but I prefer `.xindexes`. 

`xarray.Index` makes sense too. For subclasses wrapping another index class perhaps it might be still be relevant to use the `Adapter` suffix, for example to distinguish between a `pandas.Index` object and a `xarray.PandasIndexAdapter` object.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490
https://github.com/pydata/xarray/pull/5102#issuecomment-812836043,https://api.github.com/repos/pydata/xarray/issues/5102,812836043,MDEyOklzc3VlQ29tbWVudDgxMjgzNjA0Mw==,4160723,2021-04-03T08:46:23Z,2021-04-03T08:46:23Z,MEMBER,"> maybe .indexes should continue to return pandas.Index objects for now, by unwrapped IndexAdapters sorted in ._indexes?

Yes we could make a special case for pandas indexes. This would also make the refactoring easier now since `.indexes` is used internally in quite many places that expect `pandas.Index` objects. Not sure if it's a good solution in the mid/long term, though.

For example, it would be nice to move the logic implemented in `convert_label_indexer` into `PandasIndexAdapter` and `PandasMultiIndexAdapter` classes and call methods of those classes instead of dealing directly with pandas index objects. For this example (and perhaps others) we could use `_indexes` internally. Alternatively it might make sense to have an `.index_adapters` property to make things a bit clearer (this may be welcome even for internal purpose IMO).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,849315490