issue_comments: 305058643

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/1426#issuecomment-305058643 https://api.github.com/repos/pydata/xarray/issues/1426 305058643 MDEyOklzc3VlQ29tbWVudDMwNTA1ODY0Mw== 1217238 2017-05-31T01:46:35Z 2017-05-31T01:46:35Z MEMBER

If my understanding is correct, does it mean that we will support ds.sel(x='a'), ds.isel(x=[0, 1]) and ds.mean(dim='x') with your example data? Will it raise an Error if Coordinate is more than 1 dimensional? How about ds.sel(x='a', y=[1, 2])?

I was only thinking about .sel() (as works currently with MultiIndex). I'm not sure about the others yet.

@benbovy although a CoordinateGroup is definitely better than MultiIndex-scalar, it still feels like a very similar notion. It could make for a nice internal clean-up, but from an user perspective I think it's about as confusing as a MultiIndex -- it's just as many terms to keep track of.

Right now, our user facing API in xarray exposes three related concepts: - Coordinate - Index - MultiIndex

Eliminating any of these concepts would be an improvement.

To this end, I have two (vague) proposals: 1. Eliminate MultiIndex. We only have an idea of "indexed" coordinates, marked by * in the repr, which don't necessarily correspond to dimensions. Indexed coordinates, which are immutable, can have any number of dimensions and you can have any other of "indexed" coordinates per dimension. Indexing, concatenating and expanding dimensions should not change their nature. 2. Eliminate both MultiIndex and explicit indexes. Indexes required for efficient operations are created on the fly when necessary. This might be too magical.

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