issues
7 rows where state = "closed" and user = 5572303 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date), closed_at (date)
id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at ▲ | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
230529125 | MDU6SXNzdWUyMzA1MjkxMjU= | 1420 | .equals() on a coordinate takes attributes into comparison | chunweiyuan 5572303 | closed | 0 | 6 | 2017-05-22T21:48:44Z | 2019-05-23T03:11:33Z | 2019-05-23T03:11:33Z | CONTRIBUTOR | Is the following the right behavior? ```
|
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1420/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | xarray 13221727 | issue | ||||||
185017914 | MDU6SXNzdWUxODUwMTc5MTQ= | 1059 | kwarg defaults (join="inner") for DataArray._binary_ops() | chunweiyuan 5572303 | closed | 0 | 5 | 2016-10-25T04:45:28Z | 2019-01-25T16:50:56Z | 2019-01-25T16:50:56Z | CONTRIBUTOR | Currently the default is join="inner". However, there can be applications where the majority of binary operations require join="outer", not "inner". Would it be advisable to place these default values in some config object the user can set at the beginning of the run script? Or perhaps one already exists but I've failed to locate it. |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1059/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | xarray 13221727 | issue | ||||||
186036077 | MDU6SXNzdWUxODYwMzYwNzc= | 1067 | Indexing turns 1D coordinates into scalar coordinates | chunweiyuan 5572303 | closed | 0 | 1 | 2016-10-28T22:29:41Z | 2019-01-22T19:22:17Z | 2019-01-22T19:22:17Z | CONTRIBUTOR | Starting with
This will drop the index on x:
but this won't:
While the laymen would expect them both to return the same thing. Is there a reason to this design choice, or could I file a PR for it? |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1067/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | xarray 13221727 | issue | ||||||
225222227 | MDExOlB1bGxSZXF1ZXN0MTE4MjU1ODUw | 1389 | Sortby | chunweiyuan 5572303 | closed | 0 | 28 | 2017-04-29T00:44:01Z | 2017-05-12T18:36:30Z | 2017-05-12T00:29:12Z | CONTRIBUTOR | 0 | pydata/xarray/pulls/1389 |
|
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1389/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
xarray 13221727 | pull | |||||
200478981 | MDExOlB1bGxSZXF1ZXN0MTAxMzM5ODIw | 1204 | combine_first by using apply_ufunc in ops.fillna | chunweiyuan 5572303 | closed | 0 | 9 | 2017-01-12T21:03:53Z | 2017-01-23T22:43:32Z | 2017-01-23T22:39:57Z | CONTRIBUTOR | 0 | pydata/xarray/pulls/1204 | Implementing |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1204/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
xarray 13221727 | pull | |||||
186680248 | MDU6SXNzdWUxODY2ODAyNDg= | 1072 | Allow concat() to drop/replace duplicate index labels? | chunweiyuan 5572303 | closed | 0 | 26 | 2016-11-01T23:59:56Z | 2017-01-23T22:41:22Z | 2017-01-23T22:41:22Z | CONTRIBUTOR | Right now, ```
Would it be OK to introduce a kwarg ("replace"?) that replaces cells of identical coordinates from right to left? That would render ```
Some people might even want to drop all cells with coordinate collisions (probably not us). If that's the case then the kwarg would be ternary..... |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1072/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | xarray 13221727 | issue | ||||||
185794232 | MDExOlB1bGxSZXF1ZXN0OTEyOTA5MzM= | 1065 | Options to binary ops kwargs | chunweiyuan 5572303 | closed | 0 | 11 | 2016-10-27T22:17:16Z | 2016-11-12T04:00:10Z | 2016-11-12T03:59:42Z | CONTRIBUTOR | 0 | pydata/xarray/pulls/1065 | Currently the default is join="inner". However, there can be applications where the majority of binary operations require join="outer", not "inner". Addresses https://github.com/pydata/xarray/issues/1059 The solution we come up with is adding a default key/value to OPTIONS, and dynamically access/update it in code (_binary_op in both dataarray.py and dataset.py) We've also added test modules in test_dataarray.py and test_dataset.py. All tests passed. |
{ "url": "https://api.github.com/repos/pydata/xarray/issues/1065/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
xarray 13221727 | pull |
Advanced export
JSON shape: default, array, newline-delimited, object
CREATE TABLE [issues] ( [id] INTEGER PRIMARY KEY, [node_id] TEXT, [number] INTEGER, [title] TEXT, [user] INTEGER REFERENCES [users]([id]), [state] TEXT, [locked] INTEGER, [assignee] INTEGER REFERENCES [users]([id]), [milestone] INTEGER REFERENCES [milestones]([id]), [comments] INTEGER, [created_at] TEXT, [updated_at] TEXT, [closed_at] TEXT, [author_association] TEXT, [active_lock_reason] TEXT, [draft] INTEGER, [pull_request] TEXT, [body] TEXT, [reactions] TEXT, [performed_via_github_app] TEXT, [state_reason] TEXT, [repo] INTEGER REFERENCES [repos]([id]), [type] TEXT ); CREATE INDEX [idx_issues_repo] ON [issues] ([repo]); CREATE INDEX [idx_issues_milestone] ON [issues] ([milestone]); CREATE INDEX [idx_issues_assignee] ON [issues] ([assignee]); CREATE INDEX [idx_issues_user] ON [issues] ([user]);