issue_comments
3 rows where issue = 83000406 and user = 1217238 sorted by updated_at descending
This data as json, CSV (advanced)
These facets timed out: issue
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
107255997 | https://github.com/pydata/xarray/issues/411#issuecomment-107255997 | https://api.github.com/repos/pydata/xarray/issues/411 | MDEyOklzc3VlQ29tbWVudDEwNzI1NTk5Nw== | shoyer 1217238 | 2015-05-31T23:14:01Z | 2015-05-31T23:14:01Z | MEMBER | Added a warning in https://github.com/xray/xray/pull/412. Here's what that doc page looks like now: |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
unexpected positional indexing behavior with Dataset and DataArray "isel" 83000406 | |
107251624 | https://github.com/pydata/xarray/issues/411#issuecomment-107251624 | https://api.github.com/repos/pydata/xarray/issues/411 | MDEyOklzc3VlQ29tbWVudDEwNzI1MTYyNA== | shoyer 1217238 | 2015-05-31T22:03:15Z | 2015-05-31T22:03:15Z | MEMBER |
I'll definitely add a note to qualify that description in the docs -- sorry you went to all the trouble of writing up the bug report!
The open issue for this is #214, which describes how I currently do "diagonal" style indexing to extract stations. It preserves all the metadata, but is a little slow if you have a very long list of stations:. Note that the example in that first comment will work even with arrays that don't fit into memory if you use dask (which will be in the next xray release, which will be out today or tomorrow).
Full NumPy style fancy indexing is out of scope for xray. You can simply do way too many complex things with it for which preserving the metadata is impossible (e.g., you can scramble the elements of a 2D array into any arbitrary desired positions). Moreover, the underlying array indexing operations are only possible to do efficiently if the underlying array is backed by NumPy -- there's no way we'll do that with |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
unexpected positional indexing behavior with Dataset and DataArray "isel" 83000406 | |
107141480 | https://github.com/pydata/xarray/issues/411#issuecomment-107141480 | https://api.github.com/repos/pydata/xarray/issues/411 | MDEyOklzc3VlQ29tbWVudDEwNzE0MTQ4MA== | shoyer 1217238 | 2015-05-31T07:46:38Z | 2015-05-31T07:46:38Z | MEMBER | This is expected -- we do orthogonal indexing (treating each coordinate independently), not NumPy style fancy indexing. If you read on in the indexing docs, you'll find this under "Indexing details": http://xray.readthedocs.org/en/latest/indexing.html#indexing-details Perhaps we should note this more prominently! The style of indexing you're describing here is definitely useful, though (e.g., for selecting the locations of stations from a grid) -- it's something that I would really like to support. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
unexpected positional indexing behavior with Dataset and DataArray "isel" 83000406 |
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 1