issue_comments: 813090844

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/5102#issuecomment-813090844 https://api.github.com/repos/pydata/xarray/issues/5102 813090844 MDEyOklzc3VlQ29tbWVudDgxMzA5MDg0NA== 1217238 2021-04-04T19:56:51Z 2021-04-04T19:56:51Z MEMBER

Rather than xarray.IndexAdapter, maybe we should just call this new object xarray.Index? Calling this object an "adapter" diminishing its importance in Xarray's future API.

I agree that switching the return type of .indexes is probably worthy of a breaking change -- but that breaking change should be done intentionally, once the new indexing functionality works and we are ready to make a major release. We may also want a deprecation cycle. What we don't want to do is change things in an incomplete way now, in a way that makes it hard for us to issue a bug-fix release.

To make development easier, I would suggest adding a new attribute to xarray.Dataset and xarray.DataArray that exposes the new data model, e.g., perhaps .xindexes as short for "xarray indexes". We would then: 1. Immediately switch xarray to use .xindexes instead of .indexes internally. 2. Once the new indexing functionality is ready, encourage users to gradually switch from .indexes -> .xindexes by issuing a FutureWarning warning. 3. After an appropriate period of time, consider making .indexes an alias for .xindexes in a breaking release.

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