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 2272299822,PR_kwDOAMm_X85uL82a,8989,Skip flaky `test_open_mfdataset_manyfiles` test,5635139,closed,0,,,0,2024-04-30T19:24:41Z,2024-04-30T20:27:04Z,2024-04-30T19:46:34Z,MEMBER,,0,pydata/xarray/pulls/8989,"Don't just xfail, and not only on windows, since it can crash the worker ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8989/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2271670475,PR_kwDOAMm_X85uJ5Er,8988,Remove `.drop` warning allow,5635139,closed,0,,,0,2024-04-30T14:39:35Z,2024-04-30T19:26:17Z,2024-04-30T19:26:16Z,MEMBER,,0,pydata/xarray/pulls/8988,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8988/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2271652603,PR_kwDOAMm_X85uJ122,8987,Add notes on when to add ignores to warnings,5635139,closed,0,,,0,2024-04-30T14:34:52Z,2024-04-30T14:56:47Z,2024-04-30T14:56:46Z,MEMBER,,0,pydata/xarray/pulls/8987,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8987/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1250939008,I_kwDOAMm_X85Kj9CA,6646,`dim` vs `dims`,5635139,closed,0,,,4,2022-05-27T16:15:02Z,2024-04-29T18:24:56Z,2024-04-29T18:24:56Z,MEMBER,,,,"### What is your issue? I've recently been hit with this when experimenting with `xr.dot` and `xr.corr` — `xr.dot` takes `dims`, and `xr.cov` takes `dim`. Because they each take multiple arrays as positional args, kwargs are more conventional. Should we standardize on one of these?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6646/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2268058661,PR_kwDOAMm_X85t9f5f,8982,Switch all methods to `dim`,5635139,closed,0,,,0,2024-04-29T03:42:34Z,2024-04-29T18:24:56Z,2024-04-29T18:24:55Z,MEMBER,,0,pydata/xarray/pulls/8982," I _think_ this is the final set of methods - [x] Closes #6646 - [ ] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8982/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2267810980,PR_kwDOAMm_X85t8q4s,8981,Enable ffill for datetimes,5635139,closed,0,,,5,2024-04-28T20:53:18Z,2024-04-29T18:09:48Z,2024-04-28T23:02:11Z,MEMBER,,0,pydata/xarray/pulls/8981,"Notes inline. Would fix #4587 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8981/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2262478932,PR_kwDOAMm_X85tqpUi,8974,Raise errors on new warnings from within xarray,5635139,closed,0,,,2,2024-04-25T01:50:48Z,2024-04-29T12:18:42Z,2024-04-29T02:50:21Z,MEMBER,,0,pydata/xarray/pulls/8974," Notes are inline. - [x] Closes https://github.com/pydata/xarray/issues/8494 - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` --- Done with some help from an LLM — quite good for doing tedious tasks that we otherwise wouldn't want to do — can paste in all the warnings output and get a decent start on rules for exclusions","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8974/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1997537503,PR_kwDOAMm_X85fqp3A,8459,Check for aligned chunks when writing to existing variables,5635139,closed,0,,,5,2023-11-16T18:56:06Z,2024-04-29T03:05:36Z,2024-03-29T14:35:50Z,MEMBER,,0,pydata/xarray/pulls/8459,"While I don't feel super confident that this is designed to protect against any bugs, it does solve the immediate problem in #8371, by hoisting the encoding check above the code that runs for only new variables. The encoding check is somewhat implicit, so this was an easy thing to miss prior. - [x] Closes #8371, - [x] Closes #8882 - [x] Closes #8876 - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8459/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2244681150,PR_kwDOAMm_X85suxIl,8947,Add mypy to dev dependencies,5635139,closed,0,,,0,2024-04-15T21:39:19Z,2024-04-17T16:39:23Z,2024-04-17T16:39:22Z,MEMBER,,0,pydata/xarray/pulls/8947,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8947/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1960332384,I_kwDOAMm_X8502Exg,8371,Writing to regions with unaligned chunks can lose data,5635139,closed,0,,,20,2023-10-25T01:17:59Z,2024-03-29T14:35:51Z,2024-03-29T14:35:51Z,MEMBER,,,,"### What happened? Writing with `region` with chunks that aren't aligned can lose data. I've recreated an example below. While it's unlikely that folks are passing different values to `.chunk` for the template vs. the regions, I had an `""auto""` chunk, which can then set different chunk values. (FWIW, this was fairly painful, and I managed to lose a lot of time by not noticing this, and then not really considering this could happen as I was trying to debug. I think we should really strive to ensure that we don't lose data / incorrectly report that we've successfully written data...) ### What did you expect to happen? If there's a risk of data loss, raise an error... ### Minimal Complete Verifiable Example ```Python ds = xr.DataArray(np.arange(120).reshape(4,3,-1),dims=list(""abc"")).rename('var1').to_dataset().chunk(2) ds # # Dimensions: (a: 4, b: 3, c: 10) # Dimensions without coordinates: a, b, c # Data variables: # var1 (a, b, c) int64 dask.array def write(ds): ds.chunk(5).to_zarr('foo.zarr', compute=False, mode='w') for r in (range(ds.sizes['a'])): ds.chunk(3).isel(a=[r]).to_zarr('foo.zarr', region=dict(a=slice(r, r+1))) def read(ds): result = xr.open_zarr('foo.zarr') assert result.compute().identical(ds) print(result.chunksizes, ds.chunksizes) write(ds); read(ds) # AssertionError xr.open_zarr('foo.zarr').compute()['var1'] array([[[ 0, 0, 0, 3, 4, 5, 0, 0, 0, 9], [ 0, 0, 0, 13, 14, 15, 0, 0, 0, 19], [ 0, 0, 0, 23, 24, 25, 0, 0, 0, 29]], [[ 30, 31, 32, 0, 0, 35, 36, 37, 38, 0], [ 40, 41, 42, 0, 0, 45, 46, 47, 48, 0], [ 50, 51, 52, 0, 0, 55, 56, 57, 58, 0]], [[ 60, 61, 62, 0, 0, 65, 0, 0, 0, 69], [ 70, 71, 72, 0, 0, 75, 0, 0, 0, 79], [ 80, 81, 82, 0, 0, 85, 0, 0, 0, 89]], [[ 0, 0, 0, 93, 94, 95, 96, 97, 98, 0], [ 0, 0, 0, 103, 104, 105, 106, 107, 108, 0], [ 0, 0, 0, 113, 114, 115, 116, 117, 118, 0]]]) Dimensions without coordinates: a, b, c ``` ### MVCE confirmation - [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray. - [X] Complete example — the example is self-contained, including all data and the text of any traceback. - [X] Verifiable example — the example copy & pastes into an IPython prompt or [Binder notebook](https://mybinder.org/v2/gh/pydata/xarray/main?urlpath=lab/tree/doc/examples/blank_template.ipynb), returning the result. - [X] New issue — a search of GitHub Issues suggests this is not a duplicate. - [X] Recent environment — the issue occurs with the latest version of xarray and its dependencies. ### Relevant log output _No response_ ### Anything else we need to know? _No response_ ### Environment
INSTALLED VERSIONS ------------------ commit: ccc8f9987b553809fb6a40c52fa1a8a8095c8c5f python: 3.9.18 (main, Aug 24 2023, 21:19:58) [Clang 14.0.3 (clang-1403.0.22.14.1)] python-bits: 64 OS: Darwin OS-release: 22.6.0 machine: arm64 processor: arm byteorder: little LC_ALL: en_US.UTF-8 LANG: None LOCALE: ('en_US', 'UTF-8') libhdf5: None libnetcdf: None xarray: 2023.10.2.dev10+gccc8f998 pandas: 2.1.1 numpy: 1.25.2 scipy: 1.11.1 netCDF4: None pydap: None h5netcdf: None h5py: None Nio: None zarr: 2.16.0 cftime: None nc_time_axis: None PseudoNetCDF: None iris: None bottleneck: None dask: 2023.4.0 distributed: 2023.7.1 matplotlib: 3.5.1 cartopy: None seaborn: None numbagg: 0.2.3.dev30+gd26e29e fsspec: 2021.11.1 cupy: None pint: None sparse: None flox: None numpy_groupies: 0.9.19 setuptools: 68.1.2 pip: 23.2.1 conda: None pytest: 7.4.0 mypy: 1.6.0 IPython: 8.15.0 sphinx: 4.3.2
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8371/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2110888925,I_kwDOAMm_X8590Zvd,8690,Add `nbytes` to repr?,5635139,closed,0,,,9,2024-01-31T20:13:59Z,2024-02-19T22:18:47Z,2024-02-07T20:47:38Z,MEMBER,,,,"### Is your feature request related to a problem? Would having the `nbytes` value in the `Dataset` repr be reasonable? I frequently find myself logging this separately. For example: ```diff Dimensions: (lat: 25, time: 2920, lon: 53) Coordinates: * lat (lat) float32 75.0 72.5 70.0 67.5 65.0 ... 25.0 22.5 20.0 17.5 15.0 * lon (lon) float32 200.0 202.5 205.0 207.5 ... 322.5 325.0 327.5 330.0 * time (time) datetime64[ns] 2013-01-01 ... 2014-12-31T18:00:00 Data variables: - air (time, lat, lon) float32 dask.array + air (time, lat, lon) float32 15MB dask.array Attributes: Conventions: COARDS title: 4x daily NMC reanalysis (1948) description: Data is from NMC initialized reanalysis\n(4x/day). These a... platform: Model references: http://www.esrl.noaa.gov/psd/data/gridded/data.ncep.reanaly... ``` ### Describe the solution you'd like _No response_ ### Describe alternatives you've considered Status quo :) ### Additional context _No response_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8690/reactions"", ""total_count"": 6, ""+1"": 6, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2128692061,PR_kwDOAMm_X85mkDqu,8735,Remove fsspec exclusion from 2021,5635139,closed,0,,,1,2024-02-10T19:43:14Z,2024-02-11T00:19:30Z,2024-02-11T00:19:29Z,MEMBER,,0,pydata/xarray/pulls/8735,"Presumably no longer needed ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8735/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2128687154,PR_kwDOAMm_X85mkCum,8734,Silence dask doctest warning,5635139,closed,0,,,0,2024-02-10T19:25:47Z,2024-02-10T23:44:24Z,2024-02-10T23:44:24Z,MEMBER,,0,pydata/xarray/pulls/8734,"Closes #8732. Not the most elegant implementation but it's only temporary ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8734/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2126375172,I_kwDOAMm_X85-vekE,8726,PRs requiring approval & merging main?,5635139,closed,0,,,4,2024-02-09T02:35:58Z,2024-02-09T18:23:52Z,2024-02-09T18:21:59Z,MEMBER,,,,"### What is your issue? Sorry I haven't been on the calls at all recently (unfortunately the schedule is difficult for me). Maybe this was discussed there?  PRs now seem to require a separate approval prior to merging. Is there an upside to this? Is there any difference between those who can approve and those who can merge? Otherwise it just seems like more clicking. PRs also now seem to require merging the latest main prior to merging? I get there's some theoretical value to this, because changes can semantically conflict with each other. But it's extremely rare that this actually happens (can we point to cases?), and it limits the immediacy & throughput of PRs. If the bad outcome does ever happen, we find out quickly when main tests fail and can revert. (fwiw I wrote a few principles around this down a while ago [here](https://prql-lang.org/book/project/contributing/development.html#merges); those are much stronger than what I'm suggesting in this issue though)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8726/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2126095122,PR_kwDOAMm_X85mbRG7,8724,Switch `.dt` to raise an `AttributeError`,5635139,closed,0,,,0,2024-02-08T21:26:06Z,2024-02-09T02:21:47Z,2024-02-09T02:21:46Z,MEMBER,,0,pydata/xarray/pulls/8724,"Discussion at #8718 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8724/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1984961987,I_kwDOAMm_X852UB3D,8432,Writing a datetime coord ignores chunks,5635139,closed,0,,,5,2023-11-09T07:00:39Z,2024-01-29T19:12:33Z,2024-01-29T19:12:33Z,MEMBER,,,,"### What happened? When writing a coord with a datetime type, the chunking on the coord is ignored, and the whole coord is written as a single chunk. (or at least it _can_ be, I haven't done enough to confirm whether it'll always be...) This can be quite inconvenient. Any attempt to write to that dataset from a distributed process will have errors, since each process will be attempting to write another process's data, rather than only its region. And less severely, the chunks won't be unified. ### Minimal Complete Verifiable Example ```Python ds = xr.tutorial.load_dataset('air_temperature') ( ds.chunk() .expand_dims(a=1000) .assign_coords( time2=lambda x: x.time, time_int=lambda x: ((""time""), np.full(ds.sizes[""time""], 1)), ) .chunk(time=10) .to_zarr(""foo.zarr"", mode=""w"") ) xr.open_zarr('foo.zarr') # Note the `chunksize=(2920,)` vs `chunksize=(10,)`! Dimensions: (a: 1000, time: 2920, lat: 25, lon: 53) Coordinates: * lat (lat) float32 75.0 72.5 70.0 67.5 65.0 ... 22.5 20.0 17.5 15.0 * lon (lon) float32 200.0 202.5 205.0 207.5 ... 322.5 325.0 327.5 330.0 * time (time) datetime64[ns] 2013-01-01 ... 2014-12-31T18:00:00 time2 (time) datetime64[ns] dask.array # here time_int (time) int64 dask.array # here Dimensions without coordinates: a Data variables: air (a, time, lat, lon) float32 dask.array Attributes: Conventions: COARDS description: Data is from NMC initialized reanalysis\n(4x/day). These a... platform: Model references: http://www.esrl.noaa.gov/psd/data/gridded/data.ncep.reanaly... title: 4x daily NMC reanalysis (1948) xr.open_zarr('foo.zarr').chunks --------------------------------------------------------------------------- ValueError Traceback (most recent call last) Cell In[13], line 1 ----> 1 xr.open_zarr('foo.zarr').chunks File /opt/homebrew/lib/python3.9/site-packages/xarray/core/dataset.py:2567, in Dataset.chunks(self) 2552 @property 2553 def chunks(self) -> Mapping[Hashable, tuple[int, ...]]: 2554 """""" 2555 Mapping from dimension names to block lengths for this dataset's data, or None if 2556 the underlying data is not a dask array. (...) 2565 xarray.unify_chunks 2566 """""" -> 2567 return get_chunksizes(self.variables.values()) File /opt/homebrew/lib/python3.9/site-packages/xarray/core/common.py:2013, in get_chunksizes(variables) 2011 for dim, c in v.chunksizes.items(): 2012 if dim in chunks and c != chunks[dim]: -> 2013 raise ValueError( 2014 f""Object has inconsistent chunks along dimension {dim}. "" 2015 ""This can be fixed by calling unify_chunks()."" 2016 ) 2017 chunks[dim] = c 2018 return Frozen(chunks) ValueError: Object has inconsistent chunks along dimension time. This can be fixed by calling unify_chunks(). ``` ### MVCE confirmation - [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray. - [X] Complete example — the example is self-contained, including all data and the text of any traceback. - [X] Verifiable example — the example copy & pastes into an IPython prompt or [Binder notebook](https://mybinder.org/v2/gh/pydata/xarray/main?urlpath=lab/tree/doc/examples/blank_template.ipynb), returning the result. - [X] New issue — a search of GitHub Issues suggests this is not a duplicate. - [X] Recent environment — the issue occurs with the latest version of xarray and its dependencies. ### Relevant log output _No response_ ### Anything else we need to know? _No response_ ### Environment
INSTALLED VERSIONS ------------------ commit: None python: 3.9.18 (main, Nov 2 2023, 16:51:22) [Clang 14.0.3 (clang-1403.0.22.14.1)] python-bits: 64 OS: Darwin OS-release: 22.6.0 machine: arm64 processor: arm byteorder: little LC_ALL: en_US.UTF-8 LANG: None LOCALE: ('en_US', 'UTF-8') libhdf5: 1.12.2 libnetcdf: None xarray: 2023.10.1 pandas: 2.1.1 numpy: 1.26.1 scipy: 1.11.1 netCDF4: None pydap: None h5netcdf: 1.1.0 h5py: 3.8.0 Nio: None zarr: 2.16.0 cftime: 1.6.2 nc_time_axis: None PseudoNetCDF: None iris: None bottleneck: 1.3.7 dask: 2023.5.0 distributed: 2023.5.0 matplotlib: 3.6.0 cartopy: None seaborn: 0.12.2 numbagg: 0.6.0 fsspec: 2022.8.2 cupy: None pint: 0.22 sparse: 0.14.0 flox: 0.8.1 numpy_groupies: 0.9.22 setuptools: 68.2.2 pip: 23.3.1 conda: None pytest: 7.4.0 mypy: 1.6.1 IPython: 8.14.0 sphinx: 5.2.1
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8432/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2099077744,PR_kwDOAMm_X85k_vqU,8661,Add `dev` dependencies to `pyproject.toml`,5635139,closed,0,,,1,2024-01-24T20:48:55Z,2024-01-25T06:24:37Z,2024-01-25T06:24:36Z,MEMBER,,0,pydata/xarray/pulls/8661,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8661/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2097231358,PR_kwDOAMm_X85k5dSd,8648,xfail another test on windows,5635139,closed,0,,,0,2024-01-24T01:04:01Z,2024-01-24T01:23:26Z,2024-01-24T01:23:26Z,MEMBER,,0,pydata/xarray/pulls/8648,"As ever, very open to approaches to fix these. But unless we can fix them, xfailing them seems like the most reasonable solution ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8648/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2089331658,PR_kwDOAMm_X85keyUs,8624,Use ddof in `numbagg>=0.7.0` for aggregations,5635139,closed,0,,,0,2024-01-19T00:23:15Z,2024-01-23T02:25:39Z,2024-01-23T02:25:38Z,MEMBER,,0,pydata/xarray/pulls/8624,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8624/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2094956413,PR_kwDOAMm_X85kxwAk,8643,xfail zarr test on Windows,5635139,closed,0,,,0,2024-01-22T23:24:12Z,2024-01-23T00:40:29Z,2024-01-23T00:40:28Z,MEMBER,,0,pydata/xarray/pulls/8643,"I see this failing quite a lot of the time... Ofc open to a proper solution but in the meantime setting this to xfail ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8643/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092299525,PR_kwDOAMm_X85kozmg,8630,Use `T_DataArray` in `Weighted`,5635139,closed,0,,,0,2024-01-21T01:18:14Z,2024-01-22T04:28:07Z,2024-01-22T04:28:07Z,MEMBER,,0,pydata/xarray/pulls/8630,"Allows subtypes. (I had this in my git stash, so commiting it...) ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8630/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092855603,PR_kwDOAMm_X85kqlH4,8639,Silence deprecation warning from `.dims` in tests,5635139,closed,0,,,1,2024-01-22T00:25:07Z,2024-01-22T02:04:54Z,2024-01-22T02:04:53Z,MEMBER,,0,pydata/xarray/pulls/8639,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8639/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092790802,PR_kwDOAMm_X85kqX8y,8637,xfail a cftime test,5635139,closed,0,,,0,2024-01-21T21:43:59Z,2024-01-21T22:00:59Z,2024-01-21T22:00:58Z,MEMBER,,0,pydata/xarray/pulls/8637,"https://github.com/pydata/xarray/pull/8636#issuecomment-1902775153 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8637/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092777417,PR_kwDOAMm_X85kqVIH,8636,xfail another dask/pyarrow test,5635139,closed,0,,,1,2024-01-21T21:26:19Z,2024-01-21T21:42:22Z,2024-01-21T21:42:21Z,MEMBER,,0,pydata/xarray/pulls/8636,"Unsure why this wasn't showing prior -- having tests fail in the good state does make it much more difficult to ensure everything is fixed before merging. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8636/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2089351473,PR_kwDOAMm_X85ke2qd,8625,Don't show stdlib paths for `user_level_warnings`,5635139,closed,0,,,0,2024-01-19T00:45:14Z,2024-01-21T21:08:40Z,2024-01-21T21:08:39Z,MEMBER,,0,pydata/xarray/pulls/8625,"Was previously seeing: ``` :801: FutureWarning: The return type of `Dataset.dims` will be changed to return a set of dimension names in future, in order to be more consistent with `DataArray.dims`. To access a mapping from dimension names to lengths, please use `Dataset.sizes`. ``` Now: ``` /Users/maximilian/workspace/xarray/xarray/tests/test_dataset.py:701: FutureWarning: The return type of `Dataset.dims` will be changed to return a set of dimension names in future, in order to be more consistent with `DataArray.dims`. To access a mapping from dimension names to lengths, please use `Dataset.sizes`. assert ds.dims == ds.sizes ``` It's a heuristic, so not perfect, but I think very likely to be accurate. Any contrary cases very welcome... ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8625/reactions"", ""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092762468,PR_kwDOAMm_X85kqSLW,8635,xfail pyarrow test,5635139,closed,0,,,0,2024-01-21T20:42:50Z,2024-01-21T21:03:35Z,2024-01-21T21:03:34Z,MEMBER,,0,pydata/xarray/pulls/8635,"Sorry for the repeated PR -- some tests passed but some failed without pyarrow installed. So this xfails the test for the moment ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8635/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092747686,PR_kwDOAMm_X85kqPTB,8634,Workaround broken test from pyarrow,5635139,closed,0,,,0,2024-01-21T20:01:51Z,2024-01-21T20:18:23Z,2024-01-21T20:18:22Z,MEMBER,,0,pydata/xarray/pulls/8634,"While fixing the previous issue, I introduced another (but didn't see it because of the errors from the test suite, probably should have looked closer...) This doesn't fix the behavior, but I think it's minor so fine to push off. I do prioritize getting the tests where pass vs failure is meaningful again ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8634/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2092300888,PR_kwDOAMm_X85koz3r,8631,Partially fix doctests,5635139,closed,0,,,1,2024-01-21T01:25:02Z,2024-01-21T01:33:43Z,2024-01-21T01:31:46Z,MEMBER,,0,pydata/xarray/pulls/8631,"Currently getting a error without pyarrow in CI: https://github.com/pydata/xarray/actions/runs/7577666145/job/20693665924 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8631/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1923361961,I_kwDOAMm_X85ypCyp,8263,Surprising `.groupby` behavior with float index,5635139,closed,0,,,0,2023-10-03T05:50:49Z,2024-01-08T01:05:25Z,2024-01-08T01:05:25Z,MEMBER,,,,"### What is your issue? We raise an error on grouping without supplying dims, but not for float indexes — is this intentional or an oversight? > This is without `flox` installed ```python da = xr.tutorial.open_dataset(""air_temperature"")['air'] da.drop_vars('lat').groupby('lat').sum() ``` ``` --------------------------------------------------------------------------- ValueError Traceback (most recent call last) Cell In[8], line 1 ----> 1 da.drop_vars('lat').groupby('lat').sum() ... ValueError: cannot reduce over dimensions ['lat']. expected either '...' to reduce over all dimensions or one or more of ('time', 'lon'). ``` But with a float index, we don't raise: ```python da.groupby('lat').sum() ``` ...returns the original array: ``` Out[15]: array([[[296.29 , 296.79 , 297.1 , ..., 296.9 , 296.79 , 296.6 ], [295.9 , 296.19998, 296.79 , ..., 295.9 , 295.9 , 295.19998], [296.6 , 296.19998, 296.4 , ..., 295.4 , 295.1 , 294.69998], ... ``` And if we try this with a non-float index, we get the error again: ```python da.groupby('time').sum() ``` ``` ValueError: cannot reduce over dimensions ['time']. expected either '...' to reduce over all dimensions or one or more of ('lat', 'lon'). ``` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8263/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1975574237,I_kwDOAMm_X851wN7d,8409,Task graphs on `.map_blocks` with many chunks can be huge,5635139,closed,0,,,6,2023-11-03T07:14:45Z,2024-01-03T04:10:16Z,2024-01-03T04:10:16Z,MEMBER,,,,"### What happened? I'm getting task graphs > 1GB, I think possibly because the full indexes are being included in every task? ### What did you expect to happen? Only the relevant sections of the index would be included ### Minimal Complete Verifiable Example ```Python da = xr.tutorial.load_dataset('air_temperature') # Dropping the index doesn't generally matter that much... len(cloudpickle.dumps(da.chunk(lat=1, lon=1))) # 15569320 len(cloudpickle.dumps(da.chunk().drop_vars(da.indexes))) # 15477313 # But with `.map_blocks`, it really matters — it's really big with the indexes, and the same size without: len(cloudpickle.dumps(da.chunk(lat=1, lon=1).map_blocks(lambda x: x))) # 79307120 len(cloudpickle.dumps(da.chunk(lat=1, lon=1).drop_vars(da.indexes).map_blocks(lambda x: x))) # 16016173 ``` ### MVCE confirmation - [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray. - [X] Complete example — the example is self-contained, including all data and the text of any traceback. - [X] Verifiable example — the example copy & pastes into an IPython prompt or [Binder notebook](https://mybinder.org/v2/gh/pydata/xarray/main?urlpath=lab/tree/doc/examples/blank_template.ipynb), returning the result. - [X] New issue — a search of GitHub Issues suggests this is not a duplicate. - [X] Recent environment — the issue occurs with the latest version of xarray and its dependencies. ### Relevant log output _No response_ ### Anything else we need to know? _No response_ ### Environment
INSTALLED VERSIONS ------------------ commit: None python: 3.9.18 (main, Aug 24 2023, 21:19:58) [Clang 14.0.3 (clang-1403.0.22.14.1)] python-bits: 64 OS: Darwin OS-release: 22.6.0 machine: arm64 processor: arm byteorder: little LC_ALL: en_US.UTF-8 LANG: None LOCALE: ('en_US', 'UTF-8') libhdf5: 1.12.2 libnetcdf: None xarray: 2023.10.1 pandas: 2.1.1 numpy: 1.26.1 scipy: 1.11.1 netCDF4: None pydap: None h5netcdf: 1.1.0 h5py: 3.8.0 Nio: None zarr: 2.16.0 cftime: 1.6.2 nc_time_axis: None PseudoNetCDF: None iris: None bottleneck: 1.3.7 dask: 2023.5.0 distributed: 2023.5.0 matplotlib: 3.6.0 cartopy: None seaborn: 0.12.2 numbagg: 0.6.0 fsspec: 2022.8.2 cupy: None pint: 0.22 sparse: 0.14.0 flox: 0.7.2 numpy_groupies: 0.9.22 setuptools: 68.1.2 pip: 23.2.1 conda: None pytest: 7.4.0 mypy: 1.6.1 IPython: 8.14.0 sphinx: 5.2.1
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8409/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2033367994,PR_kwDOAMm_X85hj9np,8533,Offer a fixture for unifying DataArray & Dataset tests,5635139,closed,0,,,2,2023-12-08T22:06:28Z,2023-12-18T21:30:41Z,2023-12-18T21:30:40Z,MEMBER,,0,pydata/xarray/pulls/8533,Some tests are literally copy & pasted between DataArray & Dataset tests. This change allows them to use a single test. Not everything will be able to use this — sometimes we want to check specifics — but some will — I've change the `.cumulative` tests to use this fixture.,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8533/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1977661256,I_kwDOAMm_X8514LdI,8414,Is there any way of having `.map_blocks` be even more opaque to dask?,5635139,closed,0,,,23,2023-11-05T06:56:43Z,2023-12-12T18:14:57Z,2023-12-12T18:14:57Z,MEMBER,,,,"### Is your feature request related to a problem? Currently I have a workload which does something a bit like: ```python ds = open_zarr(source) ( ds.assign( x=ds.foo * ds.bar y=ds.foo + ds.bar ).to_zarr(dest) ) ``` (the actual calc is a bit more complicated! And while I don't have a MVCE of the full calc, I pasted a task graph below) Dask — while very impressive in many ways — handles this extremely badly, because it attempts to load the whole of `ds` into memory before writing out any chunks. There are lots of issues on this in the dask repo; it seems like an intractable problem for dask. ### Describe the solution you'd like I was hoping to make the internals of this task opaque to dask, so it became a much dumber task runner — just map over the blocks, running the function and writing the result, block by block. I thought I had some success with `.map_blocks` last week — the internals of the _calc_ are now opaque at least. But the dask cluster is falling over again, I think because the write is seen as a separate task. Is there any way to make the write more opaque too? ### Describe alternatives you've considered I've built a homegrown thing which is really hacky which does this on a custom scheduler — just runs the functions and writes with `region`. I'd much prefer to use & contribute to the broader ecosystem... ### Additional context (It's also possible I'm making some basic error — and I do remember it working much better last week — so please feel free to direct me / ask me for more examples, if this doesn't ring true)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8414/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2034575163,PR_kwDOAMm_X85hn4Pn,8539,Filter out doctest warning,5635139,closed,0,,,11,2023-12-10T23:11:36Z,2023-12-12T06:37:54Z,2023-12-11T21:00:01Z,MEMBER,,0,pydata/xarray/pulls/8539,"Trying to fix #8537. Not sure it'll work and can't test locally so seeing if it passes CI ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8539/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2036491126,PR_kwDOAMm_X85hud-m,8543,Fix incorrect indent,5635139,closed,0,,,0,2023-12-11T20:41:32Z,2023-12-11T20:43:26Z,2023-12-11T20:43:09Z,MEMBER,,0,pydata/xarray/pulls/8543,"edit: my mistake, this is intended","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8543/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 866826033,MDU6SXNzdWU4NjY4MjYwMzM=,5215,"Add an Cumulative aggregation, similar to Rolling",5635139,closed,0,,,6,2021-04-24T19:59:49Z,2023-12-08T22:06:53Z,2023-12-08T22:06:53Z,MEMBER,,,," **Is your feature request related to a problem? Please describe.** Pandas has a [`.expanding` aggregation](https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.expanding.html), which is basically rolling with a full lookback. I often end up supplying rolling with the length of the dimension, and this is some nice sugar for that. **Describe the solution you'd like** Basically the same as pandas — a `.expanding` method that returns an `Expanding` class, which implements the same methods as a `Rolling` class. **Describe alternatives you've considered** Some options: – This – Don't add anything, the sugar isn't worth the additional API. – Go full out and write specialized expanding algos — which will be faster since they don't have to keep track of the window. But not that much faster, likely not worth the effort.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5215/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2022202767,PR_kwDOAMm_X85g97hj,8512,Add Cumulative aggregation,5635139,closed,0,,,1,2023-12-02T21:03:13Z,2023-12-08T22:06:53Z,2023-12-08T22:06:52Z,MEMBER,,0,pydata/xarray/pulls/8512,"Closes #5215 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8512/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2019645081,I_kwDOAMm_X854YVaZ,8498,Allow some notion of ordering in Dataset dims,5635139,closed,0,,,5,2023-11-30T22:57:23Z,2023-12-08T19:22:56Z,2023-12-08T19:22:55Z,MEMBER,,,,"### What is your issue? Currently a `DataArray`'s dims are ordered, while a `Dataset`'s are not. Do we gain anything from have unordered dims in a Dataset? Could we have an ordering without enforcing it on every variable? Here's one proposal, with fairly wide error-bars: - Datasets have a dim order, which is set at construction time or through `.transpose` - Currently `.transpose` changes the order of each variable's dims, but not the dataset's - If dims aren't supplied, we can just use the first variable's - Variables don't have to conform to that order — `.assign(foo=differently_ordered)` maintains the differently ordered dims. So this doesn't limit any current functionality. - When there are transformations which change dim ordering, Xarray is ""allowed"" to transpose variables to the dataset's ordering. Currently Xarray is ""allowed"" to change dim order arbitrarily — for example to put a core dim last. IIUC, we'd prefer to set a non-arbitrary order, but we don't have one to reference. - This would remove a bunch of boilerplate from methods that save the ordering, run `.apply_ufunc` and then reorder in the original order[^1] What do folks think? [^1]: though also we could do this in `.apply_ufunc`","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8498/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,not_planned,13221727,issue 2026963757,I_kwDOAMm_X8540QMt,8522,Test failures on `main`,5635139,closed,0,,,7,2023-12-05T19:22:01Z,2023-12-06T18:48:24Z,2023-12-06T17:28:13Z,MEMBER,,,,"### What is your issue? Any ideas what could be causing these? I can't immediately reproduce locally. https://github.com/pydata/xarray/actions/runs/7105414268/job/19342564583 ``` Error: TestDataArray.test_computation_objects[int64-method_groupby_bins-data] AssertionError: Left and right DataArray objects are not close Differing values: L R ```","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8522/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 1, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1192478248,I_kwDOAMm_X85HE8Yo,6440,Add `eval`?,5635139,closed,0,,,0,2022-04-05T00:57:00Z,2023-12-06T17:52:47Z,2023-12-06T17:52:47Z,MEMBER,,,,"### Is your feature request related to a problem? We currently have [`query`](https://github.com/pydata/xarray/blob/9186540199d744c676e3ee9e829815695065e5f7/xarray/core/dataset.py), which can runs a numexpr string using `eval`. ### Describe the solution you'd like Should we add an `eval` method itself? I find that when building something for the command line, allowing people to pass an `eval`-able expression can be a good interface. ### Describe alternatives you've considered _No response_ ### Additional context _No response_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6440/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1410303926,PR_kwDOAMm_X85A3Xqk,7163,Add `eval` method to Dataset,5635139,closed,0,,,3,2022-10-15T22:12:23Z,2023-12-06T17:52:47Z,2023-12-06T17:52:46Z,MEMBER,,0,pydata/xarray/pulls/7163,"This needs proper tests & docs, but would this be a good idea? A couple of examples are in the docstring. It's mostly just deferring to pandas' excellent `eval` method. - [x] Closes #6440 (edit) - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [x] New functions/methods are listed in `api.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7163/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 1}",,,13221727,pull 2019309352,PR_kwDOAMm_X85g0KvI,8493,Use numbagg for `rolling` methods,5635139,closed,0,,,3,2023-11-30T18:52:08Z,2023-12-05T19:08:32Z,2023-12-05T19:08:31Z,MEMBER,,0,pydata/xarray/pulls/8493,"A couple of tests are failing for the multi-dimensional case, which I'll fix before merge. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8493/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 907845790,MDU6SXNzdWU5MDc4NDU3OTA=,5413,Does the PyPI release job fire twice for each release?,5635139,closed,0,,,2,2021-06-01T04:01:17Z,2023-12-04T19:22:32Z,2023-12-04T19:22:32Z,MEMBER,,,," I was attempting to copy the great work here for numbagg and spotted this! Do we fire twice for each release? Maybe that's fine though? https://github.com/pydata/xarray/actions/workflows/pypi-release.yaml ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5413/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 929840699,MDU6SXNzdWU5Mjk4NDA2OTk=,5531,"Keyword only args for arguments like ""drop""",5635139,closed,0,,,12,2021-06-25T05:24:25Z,2023-12-04T19:22:24Z,2023-12-04T19:22:23Z,MEMBER,,,," **Is your feature request related to a problem? Please describe.** A method like `.reset_index` has a signature `.reset_index(dims_or_levels, drop=False)`. This means that passing `.reset_index(""x"", ""y"")` is actually like passing `.reset_index(""x"", True)`, which is silent and confusing. **Describe the solution you'd like** Move to kwarg-only arguments for these; like `.reset_index(dims_or_levels, *, drop=False)`. But we probably need a deprecation cycle, which will require some work. **Describe alternatives you've considered** Not have a deprecation cycle? I imagine it's fairly rare to not pass the kwarg. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5531/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1165654699,I_kwDOAMm_X85Fenqr,6349,Rolling exp correlation,5635139,closed,0,,,1,2022-03-10T19:51:57Z,2023-12-04T19:13:35Z,2023-12-04T19:13:34Z,MEMBER,,,,"### Is your feature request related to a problem? I'd like an exponentially moving correlation coefficient ### Describe the solution you'd like I think we could add a `rolling_exp.corr` method fairly easily — i.e. just in python, no need to add anything to numbagg: `ewma` here means `rolling_exp(...).mean` - `ewma(A * B) - ewma(A) * ewma(B)` for the rolling covar - divided by `sqrt` of `(ewma(A**2) - ewma(A)**2` `*` `ewma(B**2) - ewma(B)**2` for the sqrt of variance We could also add a flag for cosine similarity, which wouldn't remove the mean. We could also add `.var` & `.std` & `.covar` as their own methods. I think we'd need to mask the variables on their intersection, so we don't have values that are missing from B affecting A's variance without affecting its covariance. [Pandas does this in cython](https://github.com/pandas-dev/pandas/blob/v1.4.1/pandas/_libs/window/aggregations.pyx#L1727), possibly because it's faster to only do a single pass of the data. If anyone has correctness concerns about this simple approach of wrapping `ewma`s, please let me know. Or if the performance would be unacceptable such that it shouldn't go into xarray until it's a single pass. ### Describe alternatives you've considered Numagg ### Additional context _No response_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6349/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 2019577432,PR_kwDOAMm_X85g1F3A,8495,Fix type of `.assign_coords`,5635139,closed,0,,,1,2023-11-30T21:57:58Z,2023-12-04T19:11:57Z,2023-12-04T19:11:55Z,MEMBER,,0,pydata/xarray/pulls/8495,"As discussed in #8455 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8495/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1995489227,I_kwDOAMm_X8528L_L,8455,Errors when assigning using `.from_pandas_multiindex`,5635139,closed,0,,,3,2023-11-15T20:09:15Z,2023-12-04T19:10:12Z,2023-12-04T19:10:11Z,MEMBER,,,,"### What happened? Very possibly this is user-error, forgive me if so. I'm trying to transition some code from the previous assignment of MultiIndexes, to the new world. Here's an MCVE: ### What did you expect to happen? _No response_ ### Minimal Complete Verifiable Example ```Python da = xr.tutorial.open_dataset(""air_temperature"")['air'] # old code, works, but with a warning da.expand_dims('foo').assign_coords(foo=(pd.MultiIndex.from_tuples([(1,2)]))) :1: FutureWarning: the `pandas.MultiIndex` object(s) passed as 'foo' coordinate(s) or data variable(s) will no longer be implicitly promoted and wrapped into multiple indexed coordinates in the future (i.e., one coordinate for each multi-index level + one dimension coordinate). If you want to keep this behavior, you need to first wrap it explicitly using `mindex_coords = xarray.Coordinates.from_pandas_multiindex(mindex_obj, 'dim')` and pass it as coordinates, e.g., `xarray.Dataset(coords=mindex_coords)`, `dataset.assign_coords(mindex_coords)` or `dataarray.assign_coords(mindex_coords)`. da.expand_dims('foo').assign_coords(foo=(pd.MultiIndex.from_tuples([(1,2)]))) Out[25]: array([[[[241.2 , 242.5 , 243.5 , ..., 232.79999, 235.5 , 238.59999], ... [297.69 , 298.09 , 298.09 , ..., 296.49 , 296.19 , 295.69 ]]]], dtype=float32) Coordinates: * lat (lat) float32 75.0 72.5 70.0 67.5 65.0 ... 22.5 20.0 17.5 15.0 * lon (lon) float32 200.0 202.5 205.0 207.5 ... 325.0 327.5 330.0 * time (time) datetime64[ns] 2013-01-01 ... 2014-12-31T18:00:00 * foo (foo) object MultiIndex * foo_level_0 (foo) int64 1 * foo_level_1 (foo) int64 2 # new code — seems to get confused between the number of values in the index — 1 — and the number of levels — 3 including the parent: da.expand_dims('foo').assign_coords(foo=xr.Coordinates.from_pandas_multiindex(pd.MultiIndex.from_tuples([(1,2)]), dim='foo')) --------------------------------------------------------------------------- ValueError Traceback (most recent call last) Cell In[26], line 1 ----> 1 da.expand_dims('foo').assign_coords(foo=xr.Coordinates.from_pandas_multiindex(pd.MultiIndex.from_tuples([(1,2)]), dim='foo')) File ~/workspace/xarray/xarray/core/common.py:621, in DataWithCoords.assign_coords(self, coords, **coords_kwargs) 618 else: 619 results = self._calc_assign_results(coords_combined) --> 621 data.coords.update(results) 622 return data File ~/workspace/xarray/xarray/core/coordinates.py:566, in Coordinates.update(self, other) 560 # special case for PandasMultiIndex: updating only its dimension coordinate 561 # is still allowed but depreciated. 562 # It is the only case where we need to actually drop coordinates here (multi-index levels) 563 # TODO: remove when removing PandasMultiIndex's dimension coordinate. 564 self._drop_coords(self._names - coords_to_align._names) --> 566 self._update_coords(coords, indexes) File ~/workspace/xarray/xarray/core/coordinates.py:834, in DataArrayCoordinates._update_coords(self, coords, indexes) 832 coords_plus_data = coords.copy() 833 coords_plus_data[_THIS_ARRAY] = self._data.variable --> 834 dims = calculate_dimensions(coords_plus_data) 835 if not set(dims) <= set(self.dims): 836 raise ValueError( 837 ""cannot add coordinates with new dimensions to a DataArray"" 838 ) File ~/workspace/xarray/xarray/core/variable.py:3014, in calculate_dimensions(variables) 3012 last_used[dim] = k 3013 elif dims[dim] != size: -> 3014 raise ValueError( 3015 f""conflicting sizes for dimension {dim!r}: "" 3016 f""length {size} on {k!r} and length {dims[dim]} on {last_used!r}"" 3017 ) 3018 return dims ValueError: conflicting sizes for dimension 'foo': length 1 on and length 3 on {'lat': 'lat', 'lon': 'lon', 'time': 'time', 'foo': 'foo'} ``` ### MVCE confirmation - [X] Minimal example — the example is as focused as reasonably possible to demonstrate the underlying issue in xarray. - [X] Complete example — the example is self-contained, including all data and the text of any traceback. - [X] Verifiable example — the example copy & pastes into an IPython prompt or [Binder notebook](https://mybinder.org/v2/gh/pydata/xarray/main?urlpath=lab/tree/doc/examples/blank_template.ipynb), returning the result. - [X] New issue — a search of GitHub Issues suggests this is not a duplicate. - [X] Recent environment — the issue occurs with the latest version of xarray and its dependencies. ### Relevant log output _No response_ ### Anything else we need to know? _No response_ ### Environment
INSTALLED VERSIONS ------------------ commit: None python: 3.9.18 (main, Nov 2 2023, 16:51:22) [Clang 14.0.3 (clang-1403.0.22.14.1)] python-bits: 64 OS: Darwin OS-release: 22.6.0 machine: arm64 processor: arm byteorder: little LC_ALL: en_US.UTF-8 LANG: None LOCALE: ('en_US', 'UTF-8') libhdf5: None libnetcdf: None xarray: 2023.10.2.dev10+gccc8f998 pandas: 2.1.1 numpy: 1.25.2 scipy: 1.11.1 netCDF4: None pydap: None h5netcdf: None h5py: None Nio: None zarr: 2.16.0 cftime: None nc_time_axis: None PseudoNetCDF: None iris: None bottleneck: None dask: 2023.4.0 distributed: 2023.7.1 matplotlib: 3.5.1 cartopy: None seaborn: None numbagg: 0.2.3.dev30+gd26e29e fsspec: 2021.11.1 cupy: None pint: None sparse: None flox: None numpy_groupies: 0.9.19 setuptools: 68.2.2 pip: 23.3.1 conda: None pytest: 7.4.0 mypy: 1.6.0 IPython: 8.15.0 sphinx: 4.3.2
","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8455/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,not_planned,13221727,issue 2022178394,PR_kwDOAMm_X85g92vo,8511,Allow callables to `.drop_vars`,5635139,closed,0,,,0,2023-12-02T19:39:53Z,2023-12-03T22:04:53Z,2023-12-03T22:04:52Z,MEMBER,,0,pydata/xarray/pulls/8511,"This can be used as a nice more general alternative to `.drop_indexes` or `.reset_coords(drop=True)` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8511/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2021810083,PR_kwDOAMm_X85g8r6c,8508,Implement `np.clip` as `__array_function__`,5635139,closed,0,,,2,2023-12-02T02:20:11Z,2023-12-03T05:27:38Z,2023-12-03T05:27:33Z,MEMBER,,0,pydata/xarray/pulls/8508,"Would close https://github.com/pydata/xarray/issues/2570 Because of https://numpy.org/neps/nep-0018-array-function-protocol.html#partial-implementation-of-numpy-s-api, no option is ideal: - Don't do anything — don't implement `__array_function__`. Any numpy function that's not a `ufunc` — such as `np.clip` will materialize the array into memory. - Implement `__array_function__` and lose the ability to call any non-ufunc-numpy-func that we don't explicitly configure here. So `np.lexsort(da)` wouldn't work, for example; and users would have to run `np.lexsort(da.values)`. - Implement `__array_function__`, and attempt to handle the functions we don't explicitly configure by coercing to numpy arrays. This requires writing code to walk a tree of objects looking for arrays to coerce. It seems to go against the original numpy proposal. @shoyer is this summary accurate?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8508/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2019642778,PR_kwDOAMm_X85g1URY,8497,Fully deprecate `.drop`,5635139,closed,0,,,0,2023-11-30T22:54:57Z,2023-12-02T05:52:50Z,2023-12-02T05:52:49Z,MEMBER,,0,pydata/xarray/pulls/8497,"I think it's time... ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8497/reactions"", ""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2013544848,PR_kwDOAMm_X85ggbU0,8487,Start renaming `dims` to `dim`,5635139,closed,0,,,1,2023-11-28T03:25:40Z,2023-11-28T21:04:49Z,2023-11-28T21:04:48Z,MEMBER,,0,pydata/xarray/pulls/8487,"Begins the process of #6646. I don't think it's feasible / enjoyable to do this for everything at once, so I would suggest we do it gradually, while keeping the warnings quite quiet, so by the time we convert to louder warnings, users can do a find/replace easily. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8487/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2010795504,PR_kwDOAMm_X85gXOqo,8484,Fix Zarr region transpose,5635139,closed,0,,,3,2023-11-25T21:01:28Z,2023-11-27T20:56:57Z,2023-11-27T20:56:56Z,MEMBER,,0,pydata/xarray/pulls/8484,"This wasn't working on an unregion-ed write; I think because `new_var` was being lost. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8484/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2010797682,PR_kwDOAMm_X85gXPEM,8485,Refine rolling_exp error messages,5635139,closed,0,,,0,2023-11-25T21:09:52Z,2023-11-25T21:55:20Z,2023-11-25T21:55:20Z,MEMBER,,0,pydata/xarray/pulls/8485,"(Sorry, copy & pasted too liberally!) ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8485/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1966733834,PR_kwDOAMm_X85eCSac,8389,Use numbagg for `ffill` by default,5635139,closed,0,,,5,2023-10-28T20:40:13Z,2023-11-25T21:06:10Z,2023-11-25T21:06:09Z,MEMBER,,0,pydata/xarray/pulls/8389,"The main perf advantage here is the array doesn't need to be unstacked & stacked, which is a huge win for large multi-dimensional arrays... (I actually was hitting a memory issue running an `ffill` on my own, and so thought I'd get this done!) We could move these methods to `DataWithCoords`, since they're almost the same implementation between a `DataArray` & `Dataset`, and exactly the same for numbagg's implementation --- For transparency — the logic of ""check for numbagg, check for bottleneck"" I wouldn't rate at my most confident. But I'm more confident that just installing numbagg will work. And if that works well enough, we could consider only supporting numbagg for some of these in the future. I also haven't done the benchmarks here — though the functions are relatively well benchmarked at numbagg. I'm somewhat trading off getting through these (rolling functions are coming up too) vs. doing fewer slower, and leaning towards the former, but feedback welcome... - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [x] New functions/methods are listed in `api.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8389/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1964877168,PR_kwDOAMm_X85d8EmN,8381,Allow writing to zarr with differently ordered dims,5635139,closed,0,,,2,2023-10-27T06:47:59Z,2023-11-25T21:02:20Z,2023-11-15T18:09:08Z,MEMBER,,0,pydata/xarray/pulls/8381," Is this reasonable? - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8381/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2005419839,PR_kwDOAMm_X85gFPfF,8474,"Improve ""variable not found"" error message",5635139,closed,0,,,0,2023-11-22T01:52:47Z,2023-11-24T18:49:39Z,2023-11-24T18:49:38Z,MEMBER,,0,pydata/xarray/pulls/8474," One very small step as part of https://github.com/pydata/xarray/issues/8264. The existing error is just `KeyError: 'foo`, which is annoyingly terse. Future improvements include searching for similar variable names, or even rewriting the user's calling code if there's a close variable name. This PR creates a new test file. I don't love the format here — it's difficult to snapshot an error message, so it requires copying & pasting things, which doesn't scale well, and the traceback contains environment-specific lines such that it wouldn't be feasible to paste tracebacks. ([here's](https://github.com/PRQL/prql/blob/7ef5ba9a074772fc26e8fcdf12a2a05768071948/prqlc/prql-compiler/tests/sql/error_messages.rs) what we do in PRQL, which is (immodestly) great) An alternative is just to put these in the mix of all the other tests; am open to that (and not difficult to change later)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8474/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2006891782,PR_kwDOAMm_X85gKSKW,8478,Add whatsnew for #8475,5635139,closed,0,,,0,2023-11-22T18:22:19Z,2023-11-22T18:45:23Z,2023-11-22T18:45:22Z,MEMBER,,0,pydata/xarray/pulls/8478,"Sorry, forgot in the original PR ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8478/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2005656379,PR_kwDOAMm_X85gGCSj,8475,Allow `rank` to run on dask arrays,5635139,closed,0,,,0,2023-11-22T06:22:44Z,2023-11-22T16:45:03Z,2023-11-22T16:45:02Z,MEMBER,,0,pydata/xarray/pulls/8475," - [x] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8475/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2005744975,PR_kwDOAMm_X85gGVaY,8476,Fix mypy tests,5635139,closed,0,,,0,2023-11-22T07:36:43Z,2023-11-22T08:01:13Z,2023-11-22T08:01:12Z,MEMBER,,0,pydata/xarray/pulls/8476,"I was seeing an error in #8475 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8476/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2000139267,PR_kwDOAMm_X85fzghA,8464,Fix `map_blocks` docs' formatting,5635139,closed,0,,,1,2023-11-18T01:18:02Z,2023-11-21T18:25:16Z,2023-11-21T18:25:15Z,MEMBER,,0,pydata/xarray/pulls/8464," Was looking funky. Not 100% sure this is correct but seems consistent with the others ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8464/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2000146978,PR_kwDOAMm_X85fziKs,8465,Consolidate `_get_alpha` func,5635139,closed,0,,,0,2023-11-18T01:37:25Z,2023-11-21T18:24:52Z,2023-11-21T18:24:51Z,MEMBER,,0,pydata/xarray/pulls/8465,"Am changing this a bit so starting with consolidating it rather than converting twice ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8465/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 400444797,MDExOlB1bGxSZXF1ZXN0MjQ1NjMwOTUx,2687,Enable resampling on PeriodIndex,5635139,closed,0,,,2,2019-01-17T20:13:25Z,2023-11-17T20:38:44Z,2023-11-17T20:38:44Z,MEMBER,,0,pydata/xarray/pulls/2687,"This allows resampling with `PeriodIndex` objects by keeping the `group` as an index rather than coercing to a DataArray (which coerces any non-native types to objects) I'm still getting one failure around the name of the IndexVariable still being `__resample_dim__` after resample, but wanted to socialize the approach of allowing a `name` argument to `IndexVariable` - is this reasonable? - [x] Closes https://github.com/pydata/xarray/issues/1270 - [x] 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/2687/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1980019336,I_kwDOAMm_X852BLKI,8421,`to_zarr` could transpose dims,5635139,closed,0,,,0,2023-11-06T20:38:35Z,2023-11-14T19:23:08Z,2023-11-14T19:23:08Z,MEMBER,,,,"### Is your feature request related to a problem? Currently we need to know the order of dims when using `region` in `to_zarr`. Generally in xarray we're fine with the order, because we have the names, so this is a bit of an aberration. It means that code needs to carry around the correct order of dims. Here's an MCVE: ```python ds = xr.tutorial.load_dataset('air_temperature') ds.to_zarr('foo', mode='w') ds.transpose(..., 'lat').to_zarr('foo', mode='r+') # ValueError: variable 'air' already exists with different dimension names ('time', 'lat', 'lon') != ('time', 'lon', 'lat'), but changing variable dimensions is not supported by to_zarr(). ``` ### Describe the solution you'd like I think we should be able to transpose them based on the target? ### Describe alternatives you've considered _No response_ ### Additional context _No response_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8421/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1986758555,PR_kwDOAMm_X85fGE95,8438,Rename `to_array` to `to_dataarray`,5635139,closed,0,,,2,2023-11-10T02:58:21Z,2023-11-10T06:15:03Z,2023-11-10T06:15:02Z,MEMBER,,0,pydata/xarray/pulls/8438,"This is a _very_ minor nit, so I'm not sure it's worth changing. What do others think? (I would have opened an issue but it's just as quick to just do the PR) ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8438/reactions"", ""total_count"": 3, ""+1"": 3, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1952859208,PR_kwDOAMm_X85dTmUR,8341,Deprecate tuples of chunks?,5635139,closed,0,,,1,2023-10-19T18:44:25Z,2023-10-21T01:45:28Z,2023-10-21T00:49:19Z,MEMBER,,0,pydata/xarray/pulls/8341,"(I was planning on putting an issue in, but then thought it wasn't much more difficult to make the PR. But it's totally fine if we don't think this is a good idea...) Allowing a tuple of dims means we're reliant on dimension order, which we really try and not be reliant on. It also makes the type signature even more complicated. So are we OK to encourage a dict of `dim: chunksize`, rather than a tuple of chunksizes? ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8341/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1953143391,PR_kwDOAMm_X85dUk-m,8347,2023.10.1 release notes,5635139,closed,0,,,0,2023-10-19T22:19:43Z,2023-10-19T22:42:48Z,2023-10-19T22:42:47Z,MEMBER,,0,pydata/xarray/pulls/8347,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8347/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1948037836,PR_kwDOAMm_X85dDNka,8325,internal: Improve version handling for numbagg,5635139,closed,0,,,1,2023-10-17T18:45:43Z,2023-10-19T15:59:15Z,2023-10-19T15:59:14Z,MEMBER,,0,pydata/xarray/pulls/8325,"Uses the approach in #8316, a bit nicer. Only internal. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8325/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1948548087,PR_kwDOAMm_X85dE9ga,8329,Request to adjust pyright config,5635139,closed,0,,,3,2023-10-18T01:04:00Z,2023-10-18T20:10:42Z,2023-10-18T20:10:41Z,MEMBER,,0,pydata/xarray/pulls/8329,"Would it be possible to not have this config? It overrides the local VS Code config, and means VS Code constantly is reporting errors for me. Totally open to other approaches ofc. Or that we decide that the tradeoff is worthwhile ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8329/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1948529004,PR_kwDOAMm_X85dE5aA,8327,Add docs to `reindex_like` re broadcasting,5635139,closed,0,,,0,2023-10-18T00:46:52Z,2023-10-18T18:16:43Z,2023-10-18T16:51:12Z,MEMBER,,0,pydata/xarray/pulls/8327,"This wasn't clear to me so I added some examples & a reference to `broadcast_like` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8327/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1943054301,PR_kwDOAMm_X85cyrdc,8307,"Add `corr`, `cov`, `std` & `var` to `.rolling_exp`",5635139,closed,0,,,0,2023-10-14T07:25:31Z,2023-10-18T17:35:35Z,2023-10-18T16:55:35Z,MEMBER,,0,pydata/xarray/pulls/8307,"From the new routines in numbagg. Maybe needs better tests (though these are quite heavily tested in numbagg), docs, and potentially need to think about types (maybe existing binary ops can help here?) (will fail while the build is cached on an old version of numbagg)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8307/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1948537810,PR_kwDOAMm_X85dE7Te,8328,Refine curvefit doctest,5635139,closed,0,,,0,2023-10-18T00:55:16Z,2023-10-18T01:19:27Z,2023-10-18T01:19:26Z,MEMBER,,0,pydata/xarray/pulls/8328,"A very small change ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8328/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1946081841,PR_kwDOAMm_X85c8kKB,8321,Remove a couple of trailing commas in tests,5635139,closed,0,,,0,2023-10-16T20:57:04Z,2023-10-16T21:26:50Z,2023-10-16T21:26:49Z,MEMBER,,0,pydata/xarray/pulls/8321,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8321/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1913983402,I_kwDOAMm_X85yFRGq,8233,numbagg & flox,5635139,closed,0,,,13,2023-09-26T17:33:32Z,2023-10-15T07:48:56Z,2023-10-09T15:40:29Z,MEMBER,,,,"### What is your issue? I've been doing some work recently on our old friend [numbagg](https://github.com/numbagg/numbagg), improving the ewm routines & adding some more. I'm keen to get numbagg back in shape, doing the things that it does best, and trimming anything it doesn't. I notice that it has [grouped calcs](https://github.com/numbagg/numbagg/blob/main/numbagg/grouped.py). Am I correct to think that [flox](https://github.com/xarray-contrib/flox) does this better? I haven't been up with the latest. flox looks like it's particularly focused on dask arrays, whereas [numpy_groupies](https://github.com/ml31415/numpy-groupies), one of the inspirations for this, was applicable to numpy arrays too. At least from the xarray perspective, are we OK to deprecate these numbagg functions, and direct folks to flox?","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8233/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1920172346,PR_kwDOAMm_X85blZOk,8256,Accept `lambda` for `other` param,5635139,closed,0,,,0,2023-09-30T08:24:36Z,2023-10-14T07:26:28Z,2023-09-30T18:50:33Z,MEMBER,,0,pydata/xarray/pulls/8256,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8256/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1931467868,PR_kwDOAMm_X85cLSzK,8283,Ask bug reporters to confirm they're using a recent version of xarray,5635139,closed,0,,,0,2023-10-07T19:07:17Z,2023-10-14T07:26:28Z,2023-10-09T13:30:03Z,MEMBER,,0,pydata/xarray/pulls/8283,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8283/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1931584082,PR_kwDOAMm_X85cLpuZ,8286,Fix `GroupBy` import,5635139,closed,0,,,0,2023-10-08T01:15:37Z,2023-10-14T07:26:28Z,2023-10-09T13:38:44Z,MEMBER,,0,pydata/xarray/pulls/8286,"Not sure why this only breaks tests for me, vs. in CI, but hopefully no downside to this change... ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8286/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1931581491,PR_kwDOAMm_X85cLpMS,8284,Enable `.rolling_exp` to work on dask arrays,5635139,closed,0,,,0,2023-10-08T01:06:04Z,2023-10-14T07:26:27Z,2023-10-10T06:37:20Z,MEMBER,,0,pydata/xarray/pulls/8284,"Another benefit of the move to `.apply_ufunc`... ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8284/reactions"", ""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1931582554,PR_kwDOAMm_X85cLpap,8285,Add `min_weight` param to `rolling_exp` functions,5635139,closed,0,,,2,2023-10-08T01:09:59Z,2023-10-14T07:24:48Z,2023-10-14T07:24:48Z,MEMBER,,0,pydata/xarray/pulls/8285,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8285/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1939241220,PR_kwDOAMm_X85cmBPP,8296,mypy 1.6.0 passing,5635139,closed,0,,,4,2023-10-12T06:04:46Z,2023-10-12T22:13:18Z,2023-10-12T19:06:13Z,MEMBER,,0,pydata/xarray/pulls/8296," I did the easy things, but will need help for the final couple on `_typed_ops.py` Because we don't pin mypy (should we?), this blocks other PRs if we gate them on mypy passing ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8296/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1940614908,PR_kwDOAMm_X85cqvBb,8299,xfail flaky test,5635139,closed,0,,,0,2023-10-12T19:03:59Z,2023-10-12T22:00:51Z,2023-10-12T22:00:47Z,MEMBER,,0,pydata/xarray/pulls/8299,"Would be better to fix it, but in lieu of fixing, better to skip it ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8299/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1920359276,PR_kwDOAMm_X85bl9er,8257,Mandate kwargs on `to_zarr`,5635139,closed,0,,,0,2023-09-30T18:33:13Z,2023-10-12T18:33:15Z,2023-10-04T19:05:02Z,MEMBER,,0,pydata/xarray/pulls/8257,"This aleviates some of the dangers of having these in a different order between `da` & `ds`. _Technically_ it's a breaking change, but only very technically, given that I would wager literally no one has a dozen positional arguments to this method. So I think it's OK. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8257/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1926810300,PR_kwDOAMm_X85b7rlX,8273,Allow a function in `.sortby` method,5635139,closed,0,,,0,2023-10-04T19:04:03Z,2023-10-12T18:33:14Z,2023-10-06T03:35:22Z,MEMBER,,0,pydata/xarray/pulls/8273,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8273/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1931585098,PR_kwDOAMm_X85cLp7r,8287,Rename `reset_encoding` to `drop_encoding`,5635139,closed,0,,,1,2023-10-08T01:19:25Z,2023-10-12T17:11:07Z,2023-10-12T17:11:03Z,MEMBER,,0,pydata/xarray/pulls/8287,"Closes #8259 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8287/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1920369929,I_kwDOAMm_X85ydoUJ,8259,Should `.reset_encoding` be `.drop_encoding`?,5635139,closed,0,,,1,2023-09-30T19:11:46Z,2023-10-12T17:11:06Z,2023-10-12T17:11:06Z,MEMBER,,,,"### What is your issue? Not the greatest issue facing the universe — but for the cause of consistency — should `.reset_encoding` be `.drop_encoding`, since it drops all encoding attributes? For comparison: - `.reset_coords` — ""Given names of coordinates, reset them to become variables."" - '.drop_vars` — ""Drop variables from this dataset."" Also ref #8258","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8259/reactions"", ""total_count"": 4, ""+1"": 4, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1917929597,PR_kwDOAMm_X85bd2nm,8249,Refine `chunks=None` handling,5635139,closed,0,,,0,2023-09-28T16:54:59Z,2023-10-04T18:34:27Z,2023-09-28T20:01:13Z,MEMBER,,0,pydata/xarray/pulls/8249,"Based on comment in https://github.com/pydata/xarray/pull/8247. This doesn't make it perfect, but allows the warning to get hit and clarifies the type comment, as a stop-gap","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8249/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1920167070,I_kwDOAMm_X85yc2ye,8255,Allow a `lambda` for the `other` param to `where` ,5635139,closed,0,,,1,2023-09-30T08:05:54Z,2023-09-30T19:02:42Z,2023-09-30T19:02:42Z,MEMBER,,,,"### Is your feature request related to a problem? Currently we allow: ```python da.where(lambda x: x.foo == 5) ``` ...but we don't allow: ```python da.where(lambda x: x.foo == 5, lambda x: x - x.shift(1)) ``` ...which would be nice ### Describe the solution you'd like _No response_ ### Describe alternatives you've considered I don't think this offers many downsides — it's not like we want to fill the array with a callable object. ### Additional context _No response_","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8255/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 124154674,MDU6SXNzdWUxMjQxNTQ2NzQ=,688,Keep attrs & Add a 'keep_coords' argument to Dataset.apply,5635139,closed,0,,,14,2015-12-29T02:42:48Z,2023-09-30T18:47:07Z,2023-09-30T18:47:07Z,MEMBER,,,,"Generally this isn't a problem, since the coords are carried over by the resulting `DataArray`s: ``` python In [11]: ds = xray.Dataset({ 'a':pd.DataFrame(pd.np.random.rand(10,3)), 'b':pd.Series(pd.np.random.rand(10)) }) ds.coords['c'] = pd.Series(pd.np.random.rand(10)) ds Out[11]: Dimensions: (dim_0: 10, dim_1: 3) Coordinates: * dim_0 (dim_0) int64 0 1 2 3 4 5 6 7 8 9 * dim_1 (dim_1) int64 0 1 2 c (dim_0) float64 0.9318 0.2899 0.3853 0.6235 0.9436 0.7928 ... Data variables: a (dim_0, dim_1) float64 0.5707 0.9485 0.3541 0.5987 0.406 0.7992 ... b (dim_0) float64 0.4106 0.2316 0.5804 0.6393 0.5715 0.6463 ... In [12]: ds.apply(lambda x: x*2) Out[12]: Dimensions: (dim_0: 10, dim_1: 3) Coordinates: c (dim_0) float64 0.9318 0.2899 0.3853 0.6235 0.9436 0.7928 ... * dim_0 (dim_0) int64 0 1 2 3 4 5 6 7 8 9 * dim_1 (dim_1) int64 0 1 2 Data variables: a (dim_0, dim_1) float64 1.141 1.897 0.7081 1.197 0.812 1.598 ... b (dim_0) float64 0.8212 0.4631 1.161 1.279 1.143 1.293 0.3507 ... ``` But if there's an operation that removes the coords from the `DataArray`s, the coords are not there on the result (notice `c` below). Should the `Dataset` retain them? Either _always_ or with a `keep_coords` argument, similar to `keep_attrs`. ``` python In [13]: ds = xray.Dataset({ 'a':pd.DataFrame(pd.np.random.rand(10,3)), 'b':pd.Series(pd.np.random.rand(10)) }) ds.coords['c'] = pd.Series(pd.np.random.rand(10)) ds Out[13]: Dimensions: (dim_0: 10, dim_1: 3) Coordinates: * dim_0 (dim_0) int64 0 1 2 3 4 5 6 7 8 9 * dim_1 (dim_1) int64 0 1 2 c (dim_0) float64 0.4121 0.2507 0.6326 0.4031 0.6169 0.441 0.1146 ... Data variables: a (dim_0, dim_1) float64 0.4813 0.2479 0.5158 0.2787 0.06672 ... b (dim_0) float64 0.2638 0.5788 0.6591 0.7174 0.3645 0.5655 ... In [14]: ds.apply(lambda x: x.to_pandas()*2) Out[14]: Dimensions: (dim_0: 10, dim_1: 3) Coordinates: * dim_0 (dim_0) int64 0 1 2 3 4 5 6 7 8 9 * dim_1 (dim_1) int64 0 1 2 Data variables: a (dim_0, dim_1) float64 0.9627 0.4957 1.032 0.5574 0.1334 0.8289 ... b (dim_0) float64 0.5275 1.158 1.318 1.435 0.7291 1.131 0.1903 ... ``` ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/688/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,completed,13221727,issue 1916391948,PR_kwDOAMm_X85bYlaM,8242,Add modules to `check-untyped`,5635139,closed,0,,,2,2023-09-27T21:56:45Z,2023-09-29T17:43:07Z,2023-09-29T16:39:34Z,MEMBER,,0,pydata/xarray/pulls/8242,"In reviewing https://github.com/pydata/xarray/pull/8241, I realize that we actually want `check-untyped-defs`, which is a bit less strict, but lets us add some more modules on. I did have to add a couple of ignores, think it's a reasonable tradeoff to add big modules like `computation` on. Errors with this enabled are actual type errors, not just `mypy` pedanticness, so would be good to get as much as possible into this list... ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8242/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1878288525,PR_kwDOAMm_X85ZYos5,8139,Fix pandas' `interpolate(fill_value=)` error,5635139,closed,0,,,6,2023-09-02T02:41:45Z,2023-09-28T16:48:51Z,2023-09-04T18:05:14Z,MEMBER,,0,pydata/xarray/pulls/8139,"Pandas no longer has a `fill_value` parameter for `interpolate`. Weirdly I wasn't getting this locally, on pandas 2.1.0, only in CI on https://github.com/pydata/xarray/actions/runs/6054400455/job/16431747966?pr=8138. Removing it passes locally, let's see whether this works in CI Would close #8125 ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8139/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1459938761,PR_kwDOAMm_X85DdsG-,7311,Add numba to nightly upstream,5635139,closed,0,,,2,2022-11-22T14:04:54Z,2023-09-28T16:48:16Z,2023-01-15T18:07:48Z,MEMBER,,0,pydata/xarray/pulls/7311,"I saw that we didn't have this while investigating https://github.com/numba/numba/issues/8615. We should probably wait until that's resolved before merging this (this doesn't solve that issue). ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/7311/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1249095540,PR_kwDOAMm_X844f0MK,6638,Improve perf of xr.corr,5635139,closed,0,,,1,2022-05-26T04:49:27Z,2023-09-28T16:47:12Z,2022-05-26T22:02:06Z,MEMBER,,0,pydata/xarray/pulls/6638,"I think this should improve the performance of `xr.corr` & `xr.cov`, but I'm not sure about dask arrays. I haven't been able to do tests on them, but I can do that soon unless anyone has an a priori view. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6638/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1917767929,PR_kwDOAMm_X85bdTA8,8247,Fix & normalize typing for chunks,5635139,closed,0,,,0,2023-09-28T15:17:04Z,2023-09-28T16:47:02Z,2023-09-28T16:27:43Z,MEMBER,,0,pydata/xarray/pulls/8247,"I noticed that `""auto""` wasn't allowed as a value in a dict. So this normalizes all chunk types, and defines the mapping as containing the inner type. Allows removing some ignores (though also adds one). One question — not necessary to answer now — is whether we should allow a tuple of definitions, for each dimension. Generally we use names, which helps prevent mistakes, and allows us to be less concerned about dimension ordering. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8247/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1902155047,PR_kwDOAMm_X85aonTY,8208,Use a bound `TypeVar` for `DataArray` and `Dataset` methods,5635139,closed,0,,,4,2023-09-19T03:46:33Z,2023-09-28T16:46:54Z,2023-09-19T19:20:42Z,MEMBER,,1,pydata/xarray/pulls/8208,"- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` Edit: I added a [comment](https://github.com/pydata/xarray/pull/8208#issuecomment-1725054516) outlining a problem with this --- I _think_ we should be using a `TypeVar(..., bound=...)` for our typing, since otherwise subtypes aren't allowed. I don't see a compelling reason to have all of `T_DataWithCoords` and `T_DataArrayOrSet` and `T_Xarray`, though I might be missing something. So this unifies all `T_DataWithCoords`, `T_DataArrayOrSet` and `T_Xarray` to `T_Xarray`, and changes that type to be bound on a union of `DataArray` & `Dataset` (similar to the existing `T_DataArrayOrSet`). This covers the bulk of our API — functions which transform either a `DataArray` or `Dataset` and return the input type. This does require some manual casts; I think because when there's a concrete path for both `DataArray` & `Dataset`, mypy doesn't unify them back together. It's also possible I'm missing something. One alternative — a minor change — would be to bound on `DataWithCoords`, like the existing `T_DataWithCoords`, rather than the union. A quick comparison showed each required some additional casts / ignores over the other. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8208/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1899012398,PR_kwDOAMm_X85aeNYk,8191,Fix pytest markers,5635139,closed,0,,,0,2023-09-15T20:02:52Z,2023-09-28T16:46:51Z,2023-09-15T20:27:38Z,MEMBER,,0,pydata/xarray/pulls/8191,"My mistake from #8183. I added `--strict-markers` so we can't make this sort of mistake again. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8191/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1216641509,PR_kwDOAMm_X8421nGO,6519,Scale numfocus image in readme,5635139,closed,0,,,0,2022-04-27T00:50:55Z,2023-09-28T16:46:42Z,2022-04-27T02:32:43Z,MEMBER,,0,pydata/xarray/pulls/6519,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/6519/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 909729647,MDExOlB1bGxSZXF1ZXN0NjYwMjU5NDc2,5432,Attempt to improve canonical test ds,5635139,closed,0,,,0,2021-06-02T17:35:41Z,2023-09-28T16:46:38Z,2023-09-28T16:46:37Z,MEMBER,,0,pydata/xarray/pulls/5432,"As discussed in recent issues, I'm trying to create a canonical test ds that we can base most tests off. We used to do this more often, but it's less consistent now; and arguably the existing canonical ds could be improved. The advantages of the ""canonical ds"" effort are that we can have a dataset for which operations should work — e.g. with encoding / attrs / dtypes / MultiIndexes / etc — without having to remember these for each operation, and there's a path to being able to abstract over backing stores, like we've started in `test_dataarray.py`. But this became somewhat of a yak shave — now that dims are ordered, this affects test results. So I added the ability to change dimension order in transpose, but the existing dimension order was very specific by data variable, so still lots of tests break. I'm pausing on this, but open to ideas. To handle the changing test results, I could move the ""repr""-based tests to something like pytest-regtest (which I've used myself for a while and it's pretty good, though uses file snapshots rather than inline), or doctests (pytest-accept!); otherwise changing them is very manual. Also open to feedback that this isn't somewhere to focus on consolidation, and letting tests evolve as they have been is more than fine. - [ ] Closes #xxxx - [ ] Tests added - [ ] Passes `pre-commit run --all-files` - [ ] 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/5432/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 967854972,MDExOlB1bGxSZXF1ZXN0NzEwMDA1NzY4,5694,Ask PRs to annotate tests,5635139,closed,0,,,6,2021-08-12T02:19:28Z,2023-09-28T16:46:19Z,2023-06-19T05:46:36Z,MEMBER,,0,pydata/xarray/pulls/5694," - [x] Passes `pre-commit run --all-files` - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` As discussed https://github.com/pydata/xarray/pull/5690#issuecomment-897280353","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/5694/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 430194200,MDExOlB1bGxSZXF1ZXN0MjY4MTM4OTg1,2875,DOC: More on pandas comparison,5635139,closed,0,,,2,2019-04-07T21:24:44Z,2023-09-28T16:46:14Z,2023-09-28T16:46:14Z,MEMBER,,1,pydata/xarray/pulls/2875,"Follow up from the mailing list: - Added some more thoughts on the multi-dimensional comparison. Some of this is opinionated (in concepts not arguments) so I'd appreciate feedback on both the concepts and language. - Removed some of the specific comparison with `NDPanel` etc, given those are removed - Placeholder for something on the Explicit API (wanted to get this version out, consistent with me leaving less work hanging)","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/2875/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1909747157,PR_kwDOAMm_X85bCPUt,8228,Remove an import fallback,5635139,closed,0,,,1,2023-09-23T07:11:04Z,2023-09-28T16:46:03Z,2023-09-23T19:13:14Z,MEMBER,,0,pydata/xarray/pulls/8228,"This is stable in 3.8, so we can remove the fallback now ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8228/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1903792930,PR_kwDOAMm_X85auJN5,8215,Use `TypeVar`s rather than specific unions,5635139,closed,0,,,3,2023-09-19T22:06:13Z,2023-09-24T19:40:06Z,2023-09-24T19:40:05Z,MEMBER,,0,pydata/xarray/pulls/8215,"Also from the chars of #8208 -- this uses the TypeVars we define, which hopefully sets a standard and removes ambiguity for how to type functions. It also allows subclasses. Where possible, it uses `T_Xarray`, otherwise `T_DataArrayOrSet` where it's not possible for `mypy` to narrow the concrete type down. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8215/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 1909746948,PR_kwDOAMm_X85bCPSS,8227,Add a `Literal` typing,5635139,closed,0,,,0,2023-09-23T07:10:10Z,2023-09-23T19:40:57Z,2023-09-23T19:38:05Z,MEMBER,,0,pydata/xarray/pulls/8227,,"{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8227/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull