issue_comments: 660210572
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/4212#issuecomment-660210572 | https://api.github.com/repos/pydata/xarray/issues/4212 | 660210572 | MDEyOklzc3VlQ29tbWVudDY2MDIxMDU3Mg== | 1610850 | 2020-07-17T16:36:18Z | 2020-07-17T16:36:18Z | CONTRIBUTOR | I've written this comment a few times to try and not come across as confrontational. I'm not intending to be at all, so please don't take it that way 😅. Tone is hard in comments! I'm just trying to figure out how to proceed quickly. I've noticed a diverging theme that seems to be coming up in various conversations (see #3234 and #3245) around API design for alternative array implementations. It seems to boil down to whether an array implementation has 1st party or 3rd party support within xarray. For numpy and Dask they appear to be 1st party. They influence the main API of xarray and xarray contains baked in logic to create and work with them. The work on pint so far points towards it being 3rd party. While I'm sure some compatibility code has gone into xarray much of the logic lives out in an accessor library. Given that pint is extending the numpy API this makes sense. I initially started this work assuming that cupy would be added as 1st party type, given that it attempts to replicate the numpy API without addition. However I'm not sure this is the right stance. There are a few questions such as "should I think it would help with API design and speed here if a decision were to be made about cupy (and sparse) being 1st or 3rd party. Perhaps some core maintainers could weigh in here? |
{
"total_count": 1,
"+1": 1,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
654135405 |