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/7368#issuecomment-1345646743,https://api.github.com/repos/pydata/xarray/issues/7368,1345646743,IC_kwDOAMm_X85QNPCX,1217238,2022-12-11T20:17:15Z,2022-12-11T20:17:15Z,MEMBER,"> I'm actually trying to merge `IndexedCoordinates` with `Coordinates` but I'm stuck: the latter is abstract and I don't really see how I could refactor it together with `DatasetCoordinates` and `DataArrayCoordinates`
`Coordinates` is abstract because in the (current) Xarray data model, it doesn't actually store any data -- coordinates are stored in private attributes of the original `Dataset` (`._variables` and `._coord_names`) or `DataArray` (`._coords`). So `Coordinates` needs to serve as a proxy for the data.
In the long term, I think we should refactor `Dataset`/`DataArray` to actually store data (coordinate variables, indexes and dimension sizes) on `Coordinates`, but that's a bigger refactor.
For now, it's worth noting that the current `Coordinates` class isn't actually exposed in Xarray's public API, just the `DatasetCoordinates` and `DataArrayCoordinates` classes (and not even their constructors). So the intermdiate step I would try is:
1. Rename the current `Coordinates` baseclass to `AbstractCoordinates`.
2. Rename your `IndexedCoordinates` class to `Coordinates`. Expose it in the public API. Make sure it can handle `DatasetCoordinates` and `DataArrayCoordinates` in the constructor.
3. Maybe: use some Python magic to make DatasetCorodinates/DataArrayCoordinates subclasses of the new Coordinates. Or maybe make them actual subclassses, overriding many of the methods (including the constructor).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1485037066
https://github.com/pydata/xarray/pull/7368#issuecomment-1344968954,https://api.github.com/repos/pydata/xarray/issues/7368,1344968954,IC_kwDOAMm_X85QKpj6,1217238,2022-12-10T01:37:35Z,2022-12-10T01:37:35Z,MEMBER,"Long term, do you think it would make sense to merge together Indexes, Coordinates and IndexedCoordinates? They are sort of all containers for the same thing.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1485037066
https://github.com/pydata/xarray/pull/7368#issuecomment-1344944917,https://api.github.com/repos/pydata/xarray/issues/7368,1344944917,IC_kwDOAMm_X85QKjsV,1217238,2022-12-10T00:31:46Z,2022-12-10T00:31:46Z,MEMBER,"> what do you think about the approach proposed here? I'd like to check that with you before going further with tests, docs, etc.
Generally this looks great to me!
> * How to avoid building any default index? It seems silly to add or use the `indexes` argument just for that purpose? We could address that later.
My suggestion would be:
- `coords` passed as a `dict`: create default indexes
- `coords` passed as `IndexedCoordinates`: do not create defaults
> Alternatively to an IndexedCoordinates subclass I was wondering if we could reuse the Coordinates base class?
Yes, this makes more sense to me!
> What if the Indexes class was a facade based on IndexedCoordinates instead of the other way around?
Yes, I also agree! This makes more sense.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1485037066