issue_comments

Table actions

2 rows where issue = 432798510 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

These facets timed out: author_association, issue

user 1

  • shoyer · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
482908202 https://github.com/pydata/xarray/issues/2891#issuecomment-482908202 https://api.github.com/repos/pydata/xarray/issues/2891 MDEyOklzc3VlQ29tbWVudDQ4MjkwODIwMg== shoyer 1217238 2019-04-14T00:50:37Z 2019-04-14T00:50:37Z MEMBER

OK, we would definitely welcome a pull request to improve this error message and the documentation for expand_dims!

I lean slightly against adding the copy argument since it's just as easy to add .copy() afterwards (that's one less function argument).

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   expand_dims() modifies numpy.ndarray.flags to write only, upon manually reverting this flag back, attempting to set a single inner value using .loc will instead set all of the inner array values 432798510
482880911 https://github.com/pydata/xarray/issues/2891#issuecomment-482880911 https://api.github.com/repos/pydata/xarray/issues/2891 MDEyOklzc3VlQ29tbWVudDQ4Mjg4MDkxMQ== shoyer 1217238 2019-04-13T20:30:51Z 2019-04-13T20:30:51Z MEMBER

As you've noticed, these arrays are "read only" because otherwise indexing can modify more than the original values, e.g., consider: python original = xr.DataArray(np.zeros(3), dims='x') result = original.expand_dims(y=2) result.data.flags.writeable = True result[0, 0] = 1 print(result) Both "y" values were set to 1! <xarray.DataArray (y: 2, x: 3)> array([[1., 0., 0.], [1., 0., 0.]]) Dimensions without coordinates: y, x

The work around is to call .copy() on the array after calling expand_dims(), e.g., original = xr.DataArray(np.zeros(3), dims='x') result = original.expand_dims(y=2).copy() result[0, 0] = 1 print(result) Now the correct result is printed: <xarray.DataArray (y: 2, x: 3)> array([[1., 0., 0.], [0., 0., 0.]]) Dimensions without coordinates: y, x

This is indeed intended behavior: by making the result read-only, we can expand dimensions without copying the original data, and without needing to worry about indexing modifying the wrong values.

That said, we could certainly improve the usability of this feature in xarray. Some options: - Mention the work-around of using .copy() in the error message xarray prints when an array is read-only. - Add a copy argument to expand_dims, so users can write copy=True if they want a writeable result. - Consider changing the behavior when a dimension is inserted with size 1 to make the result writeable -- in this case, individual elements of result can be modified (which will also modify the input array). But maybe it would be surprising to users if the result of expand_dims() is sometimes but not always writeable? 

{
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   expand_dims() modifies numpy.ndarray.flags to write only, upon manually reverting this flag back, attempting to set a single inner value using .loc will instead set all of the inner array values 432798510

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

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]);