home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

5 rows where issue = 1316549018 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

user 3

  • Illviljan 3
  • max-sixty 1
  • keewis 1

issue 1

  • Rely on array backend for string formatting · 5 ✖

author_association 1

  • MEMBER 5
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1203860057 https://github.com/pydata/xarray/pull/6823#issuecomment-1203860057 https://api.github.com/repos/pydata/xarray/issues/6823 IC_kwDOAMm_X85HwXJZ keewis 14808389 2022-08-03T12:03:44Z 2022-08-08T12:32:21Z MEMBER

But it won't feel very consistent once string formatting are used though.

I guess we could introduce some sort of xarray specific formatting mini-language to solve that? For example: - f"{arr:r}": print the object's repr (the default) - f"{arr:b}": print the array backend's repr (only for DataArray / Variable)

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Rely on array backend for string formatting 1316549018
1204216812 https://github.com/pydata/xarray/pull/6823#issuecomment-1204216812 https://api.github.com/repos/pydata/xarray/issues/6823 IC_kwDOAMm_X85HxuPs max-sixty 5635139 2022-08-03T16:46:19Z 2022-08-03T16:46:19Z MEMBER

Great idea — doing anything that's expensive on repr has caught us a couple of times and can be a frustrating perf issue. Thanks @Illviljan !

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Rely on array backend for string formatting 1316549018
1204156997 https://github.com/pydata/xarray/pull/6823#issuecomment-1204156997 https://api.github.com/repos/pydata/xarray/issues/6823 IC_kwDOAMm_X85HxfpF Illviljan 14371165 2022-08-03T16:05:10Z 2022-08-03T16:05:10Z MEMBER

I guess we could introduce some sort of xarray specific formatting mini-language to solve that? For example:

* `f"{arr:r}": print the object's `repr` (the default)

* `f"{arr:b}": print the array backend's `repr`(only for`DataArray`/`Variable`)

Interesting idea. I was thinking just adding format_spec to formatting.array_repr so the repr can handle __format__ as well should be enough. It seemed much more involved though.

Anyway that's for another PR. I think this PR is ready now, I think it should handle the main request in #5976 without being so intrusive in other cases.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Rely on array backend for string formatting 1316549018
1200289273 https://github.com/pydata/xarray/pull/6823#issuecomment-1200289273 https://api.github.com/repos/pydata/xarray/issues/6823 IC_kwDOAMm_X85HivX5 Illviljan 14371165 2022-07-30T20:31:01Z 2022-07-30T20:31:01Z MEMBER

This is how it behaves right now. I believe this should be the same behavior as previously now with the extra possibility to format scalar arrays:

```python import pandas as pd import xarray as xr

s = pd.Series( range(4), index=pd.MultiIndex.from_product([list("ab"), list("cd")]), )

da = xr.DataArray.from_series(s, sparse=True)

Handle sparse:

print(f"Error: {da} is sparse") Error: <xarray.DataArray (level_0: 2, level_1: 2)> <COO: shape=(2, 2), dtype=float64, nnz=4, fill_value=nan> Coordinates: * level_0 (level_0) object 'a' 'b' * level_1 (level_1) object 'c' 'd' is sparse

Handle format_spec:

da = xr.DataArray([1, 2, 3])

print(f'{da[0]}') <xarray.DataArray ()> array(1)

print(f'{da[0]:d}') 1

print(f'{da[0]:f}') 1.000000

da = xr.DataArray([1, 2, 3]) print(f'{da:.f}') Traceback (most recent call last): (...) NotImplementedError: Using format_spec is only supported when shape is (). Got shape = (3,). ```

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Rely on array backend for string formatting 1316549018
1193853083 https://github.com/pydata/xarray/pull/6823#issuecomment-1193853083 https://api.github.com/repos/pydata/xarray/issues/6823 IC_kwDOAMm_X85HKMCb Illviljan 14371165 2022-07-25T10:15:16Z 2022-07-25T10:15:16Z MEMBER

Hmm, I'm not a fan that f-strings by default uses the backend array only:

```python import pandas as pd import xarray as xr

s = pd.Series( range(4), index=pd.MultiIndex.from_product([list("ab"), list("cd")]), )

da = xr.DataArray.from_series(s, sparse=True)

Uses format:

print(f"Error: {da} is sparse") Error: <COO: shape=(2, 2), dtype=float64, nnz=4, fill_value=nan> is sparse ```

Should it by default just use the repr instead? But it won't feel very consistent once string formatting are used though.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Rely on array backend for string formatting 1316549018

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 12.757ms · About: xarray-datasette