issue_comments
6 rows where issue = 230529125 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
issue 1
- .equals() on a coordinate takes attributes into comparison · 6 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
485622616 | https://github.com/pydata/xarray/issues/1420#issuecomment-485622616 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDQ4NTYyMjYxNg== | stale[bot] 26384082 | 2019-04-23T02:48:52Z | 2019-04-23T02:48:52Z | NONE | In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity If this issue remains relevant, please comment here or remove the |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 | |
303270041 | https://github.com/pydata/xarray/issues/1420#issuecomment-303270041 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDMwMzI3MDA0MQ== | shoyer 1217238 | 2017-05-23T02:09:15Z | 2017-05-23T02:09:15Z | MEMBER | If the new rule significantly better, then breaking changes are certainly possible (in a major release). But for bars should be high: it needs to be worth potential turmoil when users update their code. For example, we could argue that I'm not sure what rule we could use for dropping scalar coordinates in particular. Adding an exception to the rules for only scalar coordinates would be a non-starter. The only alternative rule that seems at all sensible is that indexed coordinates only have the minimal set of coordinates (i.e., equivalent to calling |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 | |
303255121 | https://github.com/pydata/xarray/issues/1420#issuecomment-303255121 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDMwMzI1NTEyMQ== | chunweiyuan 5572303 | 2017-05-23T00:21:29Z | 2017-05-23T00:21:29Z | CONTRIBUTOR | This is getting close to the fundamental paradigm of xarray. Would it entail some massive code migration (and user protests) if we change how we express I'm thinking of a new API that compares only the values and indexing coordinates between two objects, but struggle to come up with a simple, descriptive name........ |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 | |
303246075 | https://github.com/pydata/xarray/issues/1420#issuecomment-303246075 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDMwMzI0NjA3NQ== | shoyer 1217238 | 2017-05-22T23:20:09Z | 2017-05-22T23:20:09Z | MEMBER |
The rule we currently use to propagate coordinates is to keep all other coordinates whose dimensions are contained in the dimensions of the coordinate, i.e., coordinates are presumed to describe not only the data-array, but an entire shared coordinate system. This is the same rule we use for choosing which coordinates to put on a DataArray when indexing a Dataset. I'm certainly open to alternatives if we can find a simple way to express this. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 | |
303244294 | https://github.com/pydata/xarray/issues/1420#issuecomment-303244294 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDMwMzI0NDI5NA== | chunweiyuan 5572303 | 2017-05-22T23:09:39Z | 2017-05-22T23:09:39Z | CONTRIBUTOR | I'm just having a hard time wrapping my head around the definitions here. Somehow it just doesn't feel right intuitively for some point dimension to mess up my comparison between two 1-D coordinates, but I might be missing some important use cases here. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 | |
303241954 | https://github.com/pydata/xarray/issues/1420#issuecomment-303241954 | https://api.github.com/repos/pydata/xarray/issues/1420 | MDEyOklzc3VlQ29tbWVudDMwMzI0MTk1NA== | shoyer 1217238 | 2017-05-22T22:54:44Z | 2017-05-22T22:54:44Z | MEMBER |
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
.equals() on a coordinate takes attributes into comparison 230529125 |
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 3