home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

4 rows where author_association = "MEMBER", issue = 200125945 and user = 4160723 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 1

  • benbovy · 4 ✖

issue 1

  • Document the new __repr__ · 4 ✖

author_association 1

  • MEMBER · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
275723498 https://github.com/pydata/xarray/issues/1199#issuecomment-275723498 https://api.github.com/repos/pydata/xarray/issues/1199 MDEyOklzc3VlQ29tbWVudDI3NTcyMzQ5OA== benbovy 4160723 2017-01-27T17:31:01Z 2017-01-27T17:31:01Z MEMBER

Nice diagram! Do you think it's worth to also add Variable and IndexVariable (along with inheritance)?

Finally I would be also +1 to do nothing with the unindexed dimensions in the repr, even though complaints for large Dataset are valid.

Although this wouldn't fully solve the problem, maybe an html repr for the notebook would help here?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Document the new __repr__ 200125945
275498595 https://github.com/pydata/xarray/issues/1199#issuecomment-275498595 https://api.github.com/repos/pydata/xarray/issues/1199 MDEyOklzc3VlQ29tbWVudDI3NTQ5ODU5NQ== benbovy 4160723 2017-01-26T20:07:25Z 2017-01-26T21:06:22Z MEMBER

We may not have gotten this right yet

I agree.

As any dimension can be indexed (at least lookup by position), the name "coordinate" may be indeed more appropriate, but we need also to make the distinction between coordinates which are IndexVariable objects and those which are Variable objects.

Any use case for dimensions which don't have an index (i.e., an IndexVariable) but have coordinates? This would be confusing too:

```

xr.Dataset({'foo': (('x', 'y'), [[1, 2], [3, 4]])}, ... {'c': (('x', 'y'), [[5, 6], [7, 8]])}) <xarray.Dataset> Dimensions: (x: 2, y: 2) Coordinates: c (x, y) int64 5 6 7 8 Data variables: foo (x, y) int64 1 2 3 4 Dimensions without coordinates: x, y ```

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Document the new __repr__ 200125945
275513365 https://github.com/pydata/xarray/issues/1199#issuecomment-275513365 https://api.github.com/repos/pydata/xarray/issues/1199 MDEyOklzc3VlQ29tbWVudDI3NTUxMzM2NQ== benbovy 4160723 2017-01-26T21:05:23Z 2017-01-26T21:05:23Z MEMBER

So the original issue was about highlighting in the repr which dimensions have an IndexVariable object and which dimensions don't.

"Dimensions without index variable" would be unambiguous in all cases, but it doesn't look nice.

Mirroring * in Dimensions is also the less ambiguous (and most concise) of the options above, but it's not very nice too (IMHO not that ugly, though).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Document the new __repr__ 200125945
272841208 https://github.com/pydata/xarray/issues/1199#issuecomment-272841208 https://api.github.com/repos/pydata/xarray/issues/1199 MDEyOklzc3VlQ29tbWVudDI3Mjg0MTIwOA== benbovy 4160723 2017-01-16T11:47:47Z 2017-01-16T11:47:47Z MEMBER

I'm still not super happy with using o in the new repr

Yes this does not seem like the best alternative.

after giving it a second thought: have you considered not to list the coordinates with "o" in the coords repr?

+1. That was the initial implementation in #1017 I think, which is the most consistent. But @crusaderky raised an issue of readability (see https://github.com/pydata/xarray/pull/1017#issuecomment-260777664).

IMO this issue of readability is more a bad habit of using the Coordinates section to actually inspect the dimensions (and thus not focusing enough on the Dimensions section), resulting from the old behavior where each dimension was guaranteed to have a (default) coordinate. Now that this is not the case anymore I wonder if new xarray users (i.e., after #1017) will encounter this issue of readability.

If this remains an issue, another option than the ones above would be to list dimensions with no index in a separate, dedicated section of the repr, e.g. with the examples above,

<xarray.Dataset> Dimensions: (dim_0: 3) Unindexed dimensions: dim_0 Data variables: var (dim_0) int64 1 2 3

<xarray.DataArray 'xy' (y: 2, x: 3)> array([[ 1.1, 2.2, 3.3], [ 4.4, 5.5, 6.6]]) Unindexed dimensions: y Coordinates: * x (x) float64 0.1 1.1 2.2 xy (y, x) float64 1.1 2.2 3.3 4.4 5.5 6.6

To not add too much verbosity, multiple dimensions without coord may be displayed inline:

<xarray.Dataset> Dimensions: (dim_0: 3, dim_1: 4) Unindexed dimensions: dim_0, dim_1 Data variables: var (dim_0) int64 1 2 3

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Document the new __repr__ 200125945

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]);
Powered by Datasette · Queries took 27.05ms · About: xarray-datasette