issue_comments: 1251975597
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/issues/7045#issuecomment-1251975597 | https://api.github.com/repos/pydata/xarray/issues/7045 | 1251975597 | IC_kwDOAMm_X85Kn6Gt | 4160723 | 2022-09-20T07:51:45Z | 2022-09-20T07:51:45Z | MEMBER |
Another solution for more flexibility or a smooth transition may be to add a build option to the
I agree, although this is getting addressed slowly but surely. In Xarray internals, most of the indexes logic is now in the IMO nearly all the complication and confusion emerge from the mixed concept of a dimension coordinate in the Xarray data model. Once the concept of an index is clearly decoupled from the concept of a coordinate and both concepts are represented as 1st-class citizens, it will help users focusing on the parts of the API and/or documentation that are relevant to their needs. It will also help "selling" Xarray to users who don't need much of the index capabilities (this has been discussed several times, either as external feedback or between Xarray devs, e.g., proposal of a "xarray-lite" package). Finally it will make more affordable major changes such as the one proposed here by @shoyer. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1376109308 |