issue_comments

Table actions

5 rows where issue = 168243768 and user = 1217238 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

user 1

  • shoyer · 5 ✖

issue 1

  • Inconsistency between the types of Dataset.dims and DataArray.dims · 5 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
457745979 https://github.com/pydata/xarray/issues/921#issuecomment-457745979 https://api.github.com/repos/pydata/xarray/issues/921 MDEyOklzc3VlQ29tbWVudDQ1Nzc0NTk3OQ== shoyer 1217238 2019-01-25T22:01:46Z 2019-01-25T22:01:46Z MEMBER

We have .sizes now.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Inconsistency between the types of Dataset.dims and DataArray.dims 168243768
255497739 https://github.com/pydata/xarray/issues/921#issuecomment-255497739 https://api.github.com/repos/pydata/xarray/issues/921 MDEyOklzc3VlQ29tbWVudDI1NTQ5NzczOQ== shoyer 1217238 2016-10-22T01:08:52Z 2016-10-22T01:08:52Z MEMBER

With optional indexes (#1017) meaning that ds.coords[...].size may not always succeed (OK, depending on some implementation choices), the need for a consistent way to look up dimension sizes becomes even more severe.

Rather than resolving the type inconsistency of dims, we could simply add a new attribute sizes to both Dataset and DataArray that is exactly equivalent to Dataset.dims. The Dataset API ends up a little bit redundant, but we have a consistent way to access this information.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Inconsistency between the types of Dataset.dims and DataArray.dims 168243768
237163191 https://github.com/pydata/xarray/issues/921#issuecomment-237163191 https://api.github.com/repos/pydata/xarray/issues/921 MDEyOklzc3VlQ29tbWVudDIzNzE2MzE5MQ== shoyer 1217238 2016-08-03T07:26:29Z 2016-08-03T07:26:29Z MEMBER

One thing I like about dims being a frozen dictionary is that is makes the fixed, immutable nature of dimension sizes on the Dataset very obvious in the data model. If you had to use ds.coords[...].size to look up dimension sizes, this would be much less obvious.

CC @jhamman in case he has thoughts here.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Inconsistency between the types of Dataset.dims and DataArray.dims 168243768
236235255 https://github.com/pydata/xarray/issues/921#issuecomment-236235255 https://api.github.com/repos/pydata/xarray/issues/921 MDEyOklzc3VlQ29tbWVudDIzNjIzNTI1NQ== shoyer 1217238 2016-07-29T17:00:24Z 2016-07-29T17:00:24Z MEMBER

I frequently need to pull out the dimension names, and I've never needed to pull out their sizes.

Indeed, this is why this discrepancy has survived for so long. Both 'foo' in x and iterations over x work the same for dictionary keys and tuples (thanks to duck typing).

Zooming out a bit: the access pattern for most of these (variables, coords) is indeed an OrderedDict of name to object. But the stickler for dim is why the size should be the value here? It seems very different from having dim objects as values.

Agreed, it is a little weird, and probably unnecessary. It is arguably a left-over from the very early days of xarray (before we had a DataArray type!).

It occurs to me that it's not hard to pull sizes out of ds.coords['time'].size if necessary, and that's probably totally sufficient for getting dimension sizes for both DataArray and Dataset. We don't really need dims_shape.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Inconsistency between the types of Dataset.dims and DataArray.dims 168243768
236097486 https://github.com/pydata/xarray/issues/921#issuecomment-236097486 https://api.github.com/repos/pydata/xarray/issues/921 MDEyOklzc3VlQ29tbWVudDIzNjA5NzQ4Ng== shoyer 1217238 2016-07-29T05:26:22Z 2016-07-29T05:26:22Z MEMBER

What are the arguments against having dims be a tuple for both DataArray & Datasets?

I guess that's a third option! In that case, we'd have to add shape to Dataset, too, to ensure there is some way to get size information.

The main downside is that we'd still be stuck without any idea way to get dimension sizes by name -- ds.shape[ds.get_axis_num('time')] is pretty bad. Also, I'm not sure how many use cases there are for actually pulling out the first dimension of a dataset (or it's shape) by position, given that dimension order is currently sorted independently of dimension order on any of its data arrays.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Inconsistency between the types of Dataset.dims and DataArray.dims 168243768

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