issue_comments: 279505323
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/1262#issuecomment-279505323 | https://api.github.com/repos/pydata/xarray/issues/1262 | 279505323 | MDEyOklzc3VlQ29tbWVudDI3OTUwNTMyMw== | 1217238 | 2017-02-13T20:00:53Z | 2017-02-13T20:09:43Z | MEMBER |
Sure, this would pretty sensible, especially if there is a nice story for wrapping upstream libraries providing alternate physical arrays such as dask.array and bolt (cc @freeman-lab). There are certainly plenty of use-cases. A few more examples that would be particularly relevant for xarray:
If we have a well defined interface that defines the right operations, my guess is indeed "yes, probably". See https://github.com/bolt-project/bolt/issues/58 for a list of operations worth considering wrapping (obviously some of these, like arithmetic, are not needed for all dtypes).
I think it should start as a separate package to ensure a cleanly separated interface and because there are definitely other clients than xarray. We can quickly add it as an optional dependency to xarray for testing purposes. I'm excited about this, but I'm unlikely to have much time available to work on this directly. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
207021356 |