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 2021585639,PR_kwDOAMm_X85g77tr,8503,Add option to define custom format of units in plots,43316012,open,0,,,5,2023-12-01T21:09:18Z,2024-02-02T22:09:11Z,,COLLABORATOR,,0,pydata/xarray/pulls/8503," - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [ ] New functions/methods are listed in `api.rst` We encountered the issue that we should plot units as `(unit)` instead of `[unit]`. This PR enables us to do exactly this, easier to change this at the source ;) I think setting this as a global option is the correct approach, but feel free to propose alternatives :)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8503/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2024737017,PR_kwDOAMm_X85hGgaB,8520,Allow configuring open_dataset via backend instances,43316012,open,0,,,9,2023-12-04T21:03:12Z,2024-01-14T21:40:38Z,,COLLABORATOR,,0,pydata/xarray/pulls/8520,"Support passing instances of `BackendEntryPoints` as the `engine` argument. Closes #8447 Then instead of passing a long list of options to the `open_dataset` method directly, you can also configure the entrypoint in the constructor and pass it as the engine. It would look something like this: ```python engine = NetCDF4BackendEntrypoint(mode=""a"", clobber=False) ds = xr.open_dataset(""some_file.nc"", engine=engine) ``` While this is actually even more lines of code, the main advantage is to have better discoverability of the options. TODO: - [x] Adapt netcdf4 backend - [x] Adapt h5netcdf backend - [x] Find out if h5netcdf backend should have ""autoclose"" and ""mode"" options (https://github.com/pydata/xarray/pull/8520#pullrequestreview-1769368001_) - [x] What to do with ""decode_vlen_strings"" option in h5netcdf (was this deprecated?) - [x] Adapt zarr backend - [x] Adapt scipy backend - [x] Adapt pydap backend - [ ] `output_grid` seems to be always set to `True`? is this intentional, why not remove it instead? - [x] ~`verify` and `user_charset` are non-existent in pydap?~ > I still had pydap version 3.2, in 3.4 they exist... - [x] typing is only my first impression. Not easy if upstream libs are untyped :/ - [x] ~Adapt pynio backend~ > Won't adapt because deprecated - [x] Fix docstrings to include init options - [x] Check if `lock=True` is allowed > Not allowed, otherwise scipy backend breaks - [ ] Change default to `lock=True` instead of `None`? Maybe a later PR? - [ ] Rename `XXXBackendEntrypoint` > `XXXBackend` ? - [x] ~The `autoclose` argument seems to do nothing?~ > Actually it is used in `BaseNetCDF4Array`, all good - [x] ~Move `group` to open_dataset instead of backend option?~ > Its not really a decoder either. Not sure, for now leave it in the init... - [ ] Improve `_resolve_decoders_kwargs`, this function has a lot of implicit assumtions? Maybe remove `open_dataset_parameters` alltogether? - [x] Add tests for passing backend directly via engine argument - [x] `open_dataset` now has `**kwargs` to support backwards compatibility. Probably we should raise if unsupported stuff is added (i.e. typos) otherwise this could be confusing? (i.e. see test in zarr that checks for deprecated `auto_chunk`)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8520/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1943539215,PR_kwDOAMm_X85c0AkW,8309,Move variable typed ops to NamedArray,43316012,open,0,,,1,2023-10-14T20:22:07Z,2023-10-26T21:55:01Z,,COLLABORATOR,,1,pydata/xarray/pulls/8309," - xref https://github.com/pydata/xarray/issues/8238 This is highly WIP and probably everything is broken right now... Just creating this now, so other people don't work on the same :) Feel free to continue here with me. @pydata/xarray 1. what do we do with commonly used functions, is it ok to copy them? 2. Moving the typed ops requires a lot of functions to be added to NamedArray, is there a consensus of what we want to move? Is it basically everything? 3. Slowly the utils module is becomming a graveyard of stuff we dont want to put elsewhere, maybe we should at least move the typing stuff over to a types module.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8309/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1928972239,PR_kwDOAMm_X85cC_Wb,8276,Give NamedArray Generic dimension type,43316012,open,0,,,3,2023-10-05T20:02:56Z,2023-10-16T13:41:45Z,,COLLABORATOR,,1,pydata/xarray/pulls/8276," - [x] Towards #8199 - [ ] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [ ] New functions/methods are listed in `api.rst` This aims at making the dimenion type a generic parameter. I thought I will start with NamedArray when testing this out because it is much less interconnected.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8276/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1368900431,PR_kwDOAMm_X84-u2Jv,7020,Typing of abstract base classes,43316012,open,0,,,6,2022-09-11T10:27:01Z,2023-01-19T10:48:20Z,,COLLABORATOR,,0,pydata/xarray/pulls/7020,"This PR adds some typing to several abstract base classes that are used in xarray. Most of it is working, only one major point I could not figure out: What is the type of `NDArrayMixin.array`??? I would appreciate it if someone that has more insight into this would help me. Several minor open points: - What is the return value of `ExplicitlyIndexed.__getitem__` - What is the return value of `ExplicitlyIndexed.transpose` - What is the return value of `AbstractArray.data` - `Variable.values` seems to be able to return scalar values which is incompatible with the `AbstractArray` definition. Overall it seems that typing has helped to find some problems again :) Mypy should fail for tests, I did not adopt them yet, want to solve the outstanding issues first.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7020/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1395053809,PR_kwDOAMm_X85AEpA1,7117,Expermimental mypy plugin,43316012,open,0,,,2,2022-10-03T17:07:59Z,2022-10-03T18:53:10Z,,COLLABORATOR,,1,pydata/xarray/pulls/7117,"I was playing around a bit with a mypy plugin and this was the best I could come up with. Unfortunately the mypy docu about the plugins is not very detailed... This plugin makes mypy recognize the user defined accessors. There is a quite severe bug in there (due to my lack of understanding of mypy internals probably) which makes it work only on the first run but when you change a line in your code and run mypy again it will crash... (you can delete the cache to make it work one more time again :) Any chance that a mypy expert can figure this out? haha","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7117/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 1, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull