issues

Table actions

6 rows where repo = 13221727, type = "pull" and user = 1828519 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

state 2

type 1

  • pull · 6 ✖

repo 1

  • xarray · 6 ✖
id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
2244518111 PR_kwDOAMm_X85suNEO 8946 Fix upcasting with python builtin numbers and numpy 2 djhoese 1828519 open 0     18 2024-04-15T20:07:42Z 2024-04-29T12:38:55Z   CONTRIBUTOR   0 pydata/xarray/pulls/8946

See #8402 for more discussion. Bottom line is that numpy 2 changes the rules for casting between two inputs. Due to this and xarray's preference for promoting python scalars to 0d arrays (scalar arrays), xarray objects are being upcast to higher data types when they previously didn't.

I'm mainly opening this PR for further and more detailed discussion.

CC @dcherian

  • [ ] Closes #8402
  • [ ] Tests added
  • [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
  • [ ] New functions/methods are listed in api.rst
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/8946/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
1750685808 PR_kwDOAMm_X85SqoXL 7905 Add '.hdf' extension to 'netcdf4' backend djhoese 1828519 open 0     10 2023-06-10T00:45:15Z 2023-06-14T15:25:08Z   CONTRIBUTOR   0 pydata/xarray/pulls/7905

I'm helping @joleenf debug an issue where some old code that uses xr.open_dataset no longer works since the introduction of engines or at least as far as we can tell. The main issue is that she's using code that assumes the NetCDF4 C library was compiled with HDF4 support (ex. conda-forge builds with this functionality enabled). So in this case netCDF4.Dataset("my_file.hdf") can actually read the HDF4 file through the NetCDF4 C library.

However, with xr.open_dataset("my_file.hdf") will fail because xarray (or rather the netcdf4 engine) doesn't know that it could potentially read HDF4 files. This PR adds the .hdf extension to the 'netcdf4' engine to allow this to be automatic without needing engine='netcdf4' to be specified.

What do people think? I didn't want to put any more work into this until others weighed in.

  • [ ] Closes #xxxx
  • [ ] Tests added
  • [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst
  • [ ] New functions/methods are listed in api.rst
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/7905/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
479640712 MDExOlB1bGxSZXF1ZXN0MzA2NDkxNzMz 3209 Add note about accessor instance creation djhoese 1828519 closed 0     1 2019-08-12T13:17:13Z 2019-08-14T13:08:54Z 2019-08-14T05:33:49Z CONTRIBUTOR   0 pydata/xarray/pulls/3209

This is an attempt at clarifying accessor docs to help with the confusion I had in #3205. I'm not sure how many other xarray doc pages use .. note:: but it seemed useable here. I'm not sure this is worth the explanation or if it is worded the best, but thought this could start the discussion.

  • [ ] Closes #3205
  • [ ] Tests added
  • [ ] Passes black . && mypy . && flake8
  • [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3209/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
453964049 MDExOlB1bGxSZXF1ZXN0Mjg2NTE1NDY4 3006 Fix 'to_masked_array' computing dask arrays twice djhoese 1828519 closed 0     6 2019-06-10T01:33:08Z 2019-06-25T16:56:19Z 2019-06-10T13:25:58Z CONTRIBUTOR   0 pydata/xarray/pulls/3006

I ran in to this issue when using imshow on a dask-based DataArray and dask's ProgressBar() context manager. I noticed that when using my_data_arr.plot.imshow the dask array was being computed twice. This PR fixes that.

Suggestions for tests and documenting this fix are welcome.

  • [ ] Closes #xxxx
  • [ ] Tests added
  • [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3006/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
403458737 MDExOlB1bGxSZXF1ZXN0MjQ3ODk5NjQ4 2715 Fix CRS being WKT instead of PROJ.4 djhoese 1828519 closed 0     13 2019-01-26T16:46:11Z 2019-03-12T18:57:44Z 2019-02-06T16:56:07Z CONTRIBUTOR   0 pydata/xarray/pulls/2715

See https://github.com/mapbox/rasterio/blob/master/CHANGES.txt#L7 for the change in rasterio 1.0.14 and my conda-forge issue where I discovered this: https://github.com/conda-forge/gdal-feedstock/issues/262

This was put in a bugfix (micro version number) release of rasterio which made it harder to discover. @sgillies @snowman2 I saw that you brought this up and how it affected xarray (https://rasterio.groups.io/g/dev/message/68). If this pull request is a duplicate of a fix one of you made let me know.

To xarray devs, if I need to make any other changes (whats-new?) also let me know.

  • [ ] Closes #xxxx
  • [ ] Tests added
  • [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2715/reactions",
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
367217516 MDExOlB1bGxSZXF1ZXN0MjIwNzA2NDkz 2465 Add python_requires to setup.py djhoese 1828519 closed 0     3 2018-10-05T13:43:06Z 2018-10-06T07:49:08Z 2018-10-06T07:48:58Z CONTRIBUTOR   0 pydata/xarray/pulls/2465

This should assist users using PyPI/pip to install xarray when xarray drops python 2.7 support. The python_requires argument is described here:

https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires

Basically, it says what versions of python your package supports. When xarray drops python 2 support and this kwarg gets update it should stop people on python 2 from getting the wrong package.

  • [x] Tests passed (for all non-documentation changes)
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/2465/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);