home / github

Menu
  • GraphQL API
  • Search all tables

issue_comments

Table actions
  • GraphQL API for issue_comments

6 rows where user = 31640292 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

issue 5

  • Xarray unable to read file that netCDF4 can 2
  • FacetGrid.set_title should allow more extensive formatting 1
  • Match all float types in formatitem 1
  • set_index does not respect keep_attrs 1
  • Generator for groupby reductions 1

user 1

  • WardBrian · 6 ✖

author_association 1

  • CONTRIBUTOR 6
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
958130347 https://github.com/pydata/xarray/pull/5871#issuecomment-958130347 https://api.github.com/repos/pydata/xarray/issues/5871 IC_kwDOAMm_X845G-ir WardBrian 31640292 2021-11-02T20:11:23Z 2021-11-02T20:11:23Z CONTRIBUTOR

the new |-operator

from __future__ import annotations does not actually directly enable the use of | for union, it changes the semantics of type annotations to postpone evaluation. In particular, you can then put just about anything in the type annotation without having any runtime behavior:

python from __future__ import annotations def foo(bar: print('hi')) -> None: pass

This is separate from PEP 604 which actually does change the syntax.

Tools like mypy will catch obvious errors like the above, and support | if they are versioned sufficiently, but it's probably not a good idea to change unless you're certain that postponing evaluation is correct (Python itself has delayed making this the default to resolve some other issues).

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Generator for groupby reductions 1028110240
821233500 https://github.com/pydata/xarray/issues/5164#issuecomment-821233500 https://api.github.com/repos/pydata/xarray/issues/5164 MDEyOklzc3VlQ29tbWVudDgyMTIzMzUwMA== WardBrian 31640292 2021-04-16T14:53:03Z 2021-04-16T14:53:48Z CONTRIBUTOR

I've been able to confirm locally that the problem is caused by the call to filters here https://github.com/pydata/xarray/blob/18ed29e4086145c29fde31c9d728a939536911c9/xarray/backends/netCDF4_.py#L395-L399

The line is even commented to say it is netcdf4 specific, but it is called unconditionally. I wrapped it in a try/except and then the file loaded, so I think this may just be an oversight in the backend

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Xarray unable to read file that netCDF4 can 859065068
820630936 https://github.com/pydata/xarray/issues/5164#issuecomment-820630936 https://api.github.com/repos/pydata/xarray/issues/5164 MDEyOklzc3VlQ29tbWVudDgyMDYzMDkzNg== WardBrian 31640292 2021-04-15T18:11:58Z 2021-04-15T18:11:58Z CONTRIBUTOR

hdf4

Yes, the only mention I can find of hdf4 for xarray relies on PyNIO, which has been discontinued. If netCDF4 can open the raw file, I'm not sure why xarray can't

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Xarray unable to read file that netCDF4 can 859065068
785734038 https://github.com/pydata/xarray/issues/4955#issuecomment-785734038 https://api.github.com/repos/pydata/xarray/issues/4955 MDEyOklzc3VlQ29tbWVudDc4NTczNDAzOA== WardBrian 31640292 2021-02-25T08:59:52Z 2021-02-25T08:59:52Z CONTRIBUTOR

Did you mean? (Notice the x.x)

Yes, my bad

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  set_index does not respect keep_attrs 816016031
727279860 https://github.com/pydata/xarray/pull/4582#issuecomment-727279860 https://api.github.com/repos/pydata/xarray/issues/4582 MDEyOklzc3VlQ29tbWVudDcyNzI3OTg2MA== WardBrian 31640292 2020-11-14T23:23:33Z 2020-11-14T23:23:33Z CONTRIBUTOR

I've added test cases for the 3 main numpy floats (16, 32, and 64 bit). In particular they are testing the rounding behavior, which differs if they are matched in the elif clauses versus if they are just cast using str()

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Match all float types in formatitem 742656246
726921555 https://github.com/pydata/xarray/issues/4575#issuecomment-726921555 https://api.github.com/repos/pydata/xarray/issues/4575 MDEyOklzc3VlQ29tbWVudDcyNjkyMTU1NQ== WardBrian 31640292 2020-11-13T17:57:48Z 2020-11-13T17:57:48Z CONTRIBUTOR

Yes, I think you could change

https://github.com/pydata/xarray/blob/b76a13f042571d01ca07461f13125a030f7297ea/xarray/core/formatting.py#L144

to np.issubdtype(x, np.floating) so it formats all floats.

This seems simple enough and fixes the main issue I was facing. I may look into the more extensible changes later if I have time, they would still be nice to have.

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  FacetGrid.set_title should allow more extensive formatting 741200389

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