home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

9 rows where author_association = "MEMBER" and issue = 1030492705 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 5

  • spencerkclark 3
  • Illviljan 2
  • keewis 2
  • dcherian 1
  • mathause 1

issue 1

  • _season_from_months can now handle np.nan · 9 ✖

author_association 1

  • MEMBER · 9 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1010114336 https://github.com/pydata/xarray/pull/5876#issuecomment-1010114336 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X848NR8g spencerkclark 6628425 2022-01-11T16:06:33Z 2022-01-11T16:06:33Z MEMBER

Thanks @pierreloicq!

{
    "total_count": 3,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 1,
    "confused": 0,
    "heart": 1,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
1008434351 https://github.com/pydata/xarray/pull/5876#issuecomment-1008434351 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X848G3yv mathause 10194086 2022-01-09T22:15:25Z 2022-01-09T22:15:25Z MEMBER

Sounds good. I think "nan" is more explicit than "".

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
1008380806 https://github.com/pydata/xarray/pull/5876#issuecomment-1008380806 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X848GquG keewis 14808389 2022-01-09T20:37:08Z 2022-01-09T20:37:08Z MEMBER

I agree. For now, it would be good to use "nan" (or ""?).

The only way to really fix this would be to introduce missing values for string dtypes, but I guess that will still take a while (unless we get pandas extension arrays to behave like duck arrays and to support n-dimensional arrays, see #5287).

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
1008312049 https://github.com/pydata/xarray/pull/5876#issuecomment-1008312049 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X848GZ7x spencerkclark 6628425 2022-01-09T14:51:33Z 2022-01-09T17:53:08Z MEMBER

@dcherian @mathause @andersy005 given a DataArray of times with missing values, do you have any thoughts on what the preferred result of da.dt.season would be?

One option would be to return np.nan in place of the missing time values:

``` In [3]: times = [np.datetime64("NaT"), np.datetime64("2000-01-01")]

In [4]: da = xr.DataArray(times, dims=["x"])

In [5]: da.dt.season Out[5]: <xarray.DataArray 'season' (x: 2)> array([nan, 'DJF'], dtype=object) Dimensions without coordinates: x ```

This would be somewhat in line with how pandas handles this in other contexts (e.g. https://github.com/pydata/xarray/pull/5876#discussion_r734447120). But this sort of awkwardly returns a DataArray of mixed types. Another option, and this is how @pierreloicq implemented things originally, would be to simply return a string label for missing values, e.g.

In [5]: da.dt.season Out[5]: <xarray.DataArray 'season' (x: 2)> array(['nan', 'DJF'], dtype='<U32') Dimensions without coordinates: x

As I've thought about this more, this feels nicer, because the types are consistent and "season" is just a category label, and "nan" categorizes these values just as well as np.nan. Do you agree?

{
    "total_count": 3,
    "+1": 3,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
1008341982 https://github.com/pydata/xarray/pull/5876#issuecomment-1008341982 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X848GhPe dcherian 2448579 2022-01-09T17:36:55Z 2022-01-09T17:36:55Z MEMBER

As I've thought about this more, this feels nicer, because the types are consistent and "season" is a just a category label, and "nan" categorizes these values just as well as np.nan.

I prefer this from a user perspective. It's nice not to have to deal with mixed types and object arrays.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
973649826 https://github.com/pydata/xarray/pull/5876#issuecomment-973649826 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X846CLei spencerkclark 6628425 2021-11-19T01:41:05Z 2021-11-19T01:41:05Z MEMBER

No worries about the cftime tests by the way -- how to best handle missing values in that context is still somewhat of an open question (https://github.com/Unidata/cftime/issues/145).

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
957894785 https://github.com/pydata/xarray/pull/5876#issuecomment-957894785 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X845GFCB keewis 14808389 2021-11-02T16:12:17Z 2021-11-02T16:12:17Z MEMBER

that's a random error that sometimes happens with mamba in CI. I've restarted the CI, hopefully it will pass now.

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
949270052 https://github.com/pydata/xarray/pull/5876#issuecomment-949270052 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X844lLYk Illviljan 14371165 2021-10-22T04:08:59Z 2021-10-22T04:08:59Z MEMBER

The code linting errors are still there and needs to be fixed, you can copy those changes to get that check passing. We use black for the code formatting, so if you run it there should be no code formatting differences, or run the pre-commit which also runs black. See http://xarray.pydata.org/en/stable/contributing.html

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705
948893303 https://github.com/pydata/xarray/pull/5876#issuecomment-948893303 https://api.github.com/repos/pydata/xarray/issues/5876 IC_kwDOAMm_X844jvZ3 Illviljan 14371165 2021-10-21T18:29:44Z 2021-10-21T18:29:44Z MEMBER

=========================== short test summary info ============================ FAILED xarray/tests/test_backends.py::TestPseudoNetCDFFormat::test_ict_format FAILED xarray/tests/test_backends.py::TestPseudoNetCDFFormat::test_ict_format_write = 2 failed, 13692 passed, 1110 skipped, 226 xfailed, 66 xpassed, 128 warnings in 549.50s (0:09:09) = Will be fixed in #5875.

But there's a few code linting errors which pep8speaks is also complaining about.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  _season_from_months can now handle np.nan 1030492705

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