issue_comments: 524569964
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/525#issuecomment-524569964 | https://api.github.com/repos/pydata/xarray/issues/525 | 524569964 | MDEyOklzc3VlQ29tbWVudDUyNDU2OTk2NA== | 1217238 | 2019-08-24T18:03:24Z | 2019-08-24T18:03:24Z | MEMBER | That said, I agree that the dedicated accessor is a pretty good interface, especially if you want more methods/property than The accessor route is also definitely more conservative than putting first-class unit support in xarray proper, which I like. As for where to put it, that's sort of up to you. I think it's probably going to get complicated enough that it should into a library that can be installed, rather than being a boilerplate example in xarray's docs. It could be in xarray if it's going to be very minimal (e.g., only one method + one property) but if you want more than that -- and judging by pint-pandas I would guess you do -- then it should probably go into pint or a dedicated package, e.g., pint-xarray. I would not write a general purpose xarray+units library unless you're particularly excited about doing that for some reason -- it's much better to start with a particular integration that works well than to make a half-hearted effort at something general purpose without well-motivated use-cases. |
{
"total_count": 0,
"+1": 0,
"-1": 0,
"laugh": 0,
"hooray": 0,
"confused": 0,
"heart": 0,
"rocket": 0,
"eyes": 0
} |
100295585 |