issue_comments
7 rows where author_association = "MEMBER" and issue = 207021356 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Logical DTypes · 7 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
751361296 | https://github.com/pydata/xarray/issues/1262#issuecomment-751361296 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDc1MTM2MTI5Ng== | keewis 14808389 | 2020-12-26T14:25:57Z | 2020-12-26T14:25:57Z | MEMBER | there is now a series of NEPs starting with NEP-40 discussing this, so we should be able to wait until |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279861287 | https://github.com/pydata/xarray/issues/1262#issuecomment-279861287 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTg2MTI4Nw== | clarkfitzg 5356122 | 2017-02-14T22:47:28Z | 2017-02-14T22:47:28Z | MEMBER | Other datatypes would be extremely useful. But I think it would be better to start as a separate project and build some confidence in a system first. @MaximilianR I was just typing nearly the same thing... :+1:
Pandas seems to be moving away from this approach now. Any other existing alternatives? datashape? |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279854154 | https://github.com/pydata/xarray/issues/1262#issuecomment-279854154 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTg1NDE1NA== | max-sixty 5635139 | 2017-02-14T22:17:40Z | 2017-02-14T22:17:40Z | MEMBER | Worth considering pandas 2.0 discussions around types https://github.com/pandas-dev/pandas2/issues/24, and some of their rejected considerations, such as https://github.com/libdynd/libdynd |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279846111 | https://github.com/pydata/xarray/issues/1262#issuecomment-279846111 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTg0NjExMQ== | shoyer 1217238 | 2017-02-14T21:46:09Z | 2017-02-14T21:46:09Z | MEMBER | CC @pydata/xarray in case anyone else has opinions here
We really don't have much existing machinery. Two things we have that might be useful:
Fewer libraries is definitely nice, but I see this as more of a secondary rather than primary goal. More broadly, doing this project right will need strong separation of concerns from xarray's handling of labeled arrays. So there's not a huge amount to be gained by doing it in the same repository.
I would love to see this project be successful and integrated with xarray. But better dtypes is tangental to our current focus, and project maintenance is already stretched pretty thin -- there's still a lot of core functionality to build out for manipulation of labeled arrays. So I'm not comfortable with building this in xarray at this time. But I would be happy to revisit this decision when you have a design document, prototype and someone committed to developing and maintaining the module. |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279515654 | https://github.com/pydata/xarray/issues/1262#issuecomment-279515654 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTUxNTY1NA== | mrocklin 306380 | 2017-02-13T20:41:50Z | 2017-02-13T20:41:50Z | MEMBER | To be clear, my original question was more ambitious. It may be interpreted as "should such a system be integrated directly into the XArray codebase?" The answer of "No, it should be a standalone library that XArray wraps much in the same way it wraps around numpy or dask.array" if fine with me. Just asking. Benefits in favor would be that I suspect XArray already has mechanisms for coercion and such and it would reduce the number of total libraries. Argument against is that XArray is currently only focused on indexed and labeled arrays, and possible it doesn't want to deal with the dtype mess. So, more broadly, the question is "What is the scope of XArray?" |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279509836 | https://github.com/pydata/xarray/issues/1262#issuecomment-279509836 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTUwOTgzNg== | shoyer 1217238 | 2017-02-13T20:18:42Z | 2017-02-13T20:18:42Z | MEMBER | One major API design challenge to solve with such a package (unresolved in NumPy) is how to handle dtype-specific methods/properties, e.g., Fitting these into a generic |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Logical DTypes 207021356 | |
279505323 | https://github.com/pydata/xarray/issues/1262#issuecomment-279505323 | https://api.github.com/repos/pydata/xarray/issues/1262 | MDEyOklzc3VlQ29tbWVudDI3OTUwNTMyMw== | shoyer 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 } |
Logical DTypes 207021356 |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issue_comments] ( [html_url] TEXT, [issue_url] TEXT, [id] INTEGER PRIMARY KEY, [node_id] TEXT, [user] INTEGER REFERENCES [users]([id]), [created_at] TEXT, [updated_at] TEXT, [author_association] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [issue] INTEGER REFERENCES [issues]([id]) ); CREATE INDEX [idx_issue_comments_issue] ON [issue_comments] ([issue]); CREATE INDEX [idx_issue_comments_user] ON [issue_comments] ([user]);
user 5