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 |