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 2152779535,PR_kwDOAMm_X85n15Fl,8784,Do not attempt to broadcast when global option ``arithmetic_broadcast=False``,45271239,closed,0,,,1,2024-02-25T14:00:57Z,2024-03-13T15:36:34Z,2024-03-13T15:36:34Z,CONTRIBUTOR,,0,pydata/xarray/pulls/8784,"**Follow-up PR after #8698** - [x] Closes #6806 - [x] Tests added - [x] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [x] What's new entry - [x] Refer to PR ID (cannot be done before the PR has been created) - [x] New functions/methods are listed in `api.rst` - No new functions/methods. ## Motive Refer to #8698 for history In this PR more specifically: - Added a global option, `arithmetic_broadcast`, `=True` by default (current state) - If `arithmetic_broadcast=False` , [`_binary_op`](https://github.com/pydata/xarray/pull/8784/files#diff-43c76e9be8425b5b6897dcecab4b240c32580447455c0c8c0b9b7fd84ce8a15dR2270) raises an error with message: ``` arithmetic broadcast is disabled via global option ``` ## Unrelated Also adds a decorator to handle the optional dependency `dask_expr`","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8784/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2140225209,PR_kwDOAMm_X85nLLgJ,8761,Use ruff for formatting,45271239,open,0,,,10,2024-02-17T16:04:18Z,2024-02-27T20:11:57Z,,CONTRIBUTOR,,1,pydata/xarray/pulls/8761," - [ ] Closes #8760 ~~- [ ] Tests added~~ ~~- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`~~ ~~- [ ] New functions/methods are listed in `api.rst`~~ Note: many inline `...` obtain their own line. Running `black .` would have produced the same result ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8761/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2127814221,PR_kwDOAMm_X85mhHB1,8729,Reinforce alignment checks when `join='exact'`,45271239,closed,0,,,0,2024-02-09T20:36:46Z,2024-02-25T12:51:54Z,2024-02-25T12:51:54Z,CONTRIBUTOR,,1,pydata/xarray/pulls/8729," :information_source: Companion PR of #8698 Aims to check the consequences of transforming `join='exact'` aligments into `join='strict'` ones.","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8729/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2116618415,PR_kwDOAMm_X85l7Cdb,8698,New alignment option: `join='strict'`,45271239,closed,0,,,5,2024-02-03T17:58:43Z,2024-02-25T09:09:37Z,2024-02-25T09:09:37Z,CONTRIBUTOR,,0,pydata/xarray/pulls/8698," Title: New alignment option: `join='strict'` - [ ] Closes #8231 - [x] Closes #6806 - [x] Tests added - [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst` - [x] What's new entry - [x] Refer to PR ID (cannot be done before the PR has been created) - [x] New functions/methods are listed in `api.rst` - No new functions/methods. ## Motive This PR is motivated by solving of the following issues: - xr.concat concatenates along dimensions that it wasn't asked to #8231 - New alignment option: ""exact"" without broadcasting OR Turn off automatic broadcasting #6806 **The current PR does not solve the unexpected issue described in #8231 without a change in user-code**. Indeed, in the tests written, it is shown that to get the said expected behavior, the user would have to use the new `join='strict'` mode suggested in #6806 for the concatenation operation. Only in that case, the uniqueness of the indexed dimensions' names will be checked, re-using the same logic that was already applied for `join='override'` in `Aligner.find_matching_indexes` This may not be enough to fix #8231. If that isn't, I can split the PR into two, first one for adding the `join='strict'` for #6806 and later on one for #8321. ## Technical Details I try to detail here my thought process. Please correct me if there is anything wrong. This is my first time digging into this core logic! Here is my understanding of the terms: - An **indexed dimension** is attached to a coordinate variable - An **unindexed dimension** is not attached to a coordinate variable (_""Dimensions without coordinates""_) Input data for Scenario 1, tested in `test_concat_join_coordinate_variables_non_asked_dims` ```python ds1 = Dataset( coords={ ""x_center"": (""x_center"", [1, 2, 3]), ""x_outer"": (""x_outer"", [0.5, 1.5, 2.5, 3.5]), }, ) ds2 = Dataset( coords={ ""x_center"": (""x_center"", [4, 5, 6]), ""x_outer"": (""x_outer"", [4.5, 5.5, 6.5]), }, ) ``` Input data for Scenario 2, tested in `test_concat_join_non_coordinate_variables` ```python ds1 = Dataset( data_vars={ ""a"": (""x_center"", [1, 2, 3]), ""b"": (""x_outer"", [0.5, 1.5, 2.5, 3.5]), }, ) ds2 = Dataset( data_vars={ ""a"": (""x_center"", [4, 5, 6]), ""b"": (""x_outer"", [4.5, 5.5, 6.5]), }, ) ``` Logic for non-indexed dimensions logic was working ""as expected"", as it relies on `Aligner.assert_unindexed_dim_sizes_equal`, checking that unindexed dimension sizes are equal as its name suggests. (Scenario 1) However, the logic for indexed dimensions was surprising as such an expected check on dimensions' sizes was not performed. A check exists in `Aligner.find_matching_indexes` but was only applied to `join='override'`. Applying it for `join='strict'` too is suggested in this Pull Request. ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8698/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2117187646,PR_kwDOAMm_X85l85Qf,8702,Add a simple `nbytes` representation in DataArrays and Dataset `repr`,45271239,closed,0,,,23,2024-02-04T16:37:41Z,2024-02-20T11:15:51Z,2024-02-07T20:47:37Z,CONTRIBUTOR,,0,pydata/xarray/pulls/8702," Edit: in contrary to what the title suggest, this is not an opt-in feature, it is enabled by default - [x] Closes #8690 - (or at least is a proposal) - [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`~~ ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8702/reactions"", ""total_count"": 1, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 1, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull 2123948734,PR_kwDOAMm_X85mT5_9,8719,Test formatting platform,45271239,closed,0,,,2,2024-02-07T21:41:23Z,2024-02-09T03:01:35Z,2024-02-09T03:01:35Z,CONTRIBUTOR,,0,pydata/xarray/pulls/8719,"Follow up #8702 / https://github.com/pydata/xarray/pull/8702#issuecomment-1932851112 The goal is to remove the not elegant OS-dependant checks introduced during the testing of #8702 A simple way to do so is to use unsigned integer as dtypes for tests involving data array representations on multiple OSes. Indeed, this solves the issue of the default dtypes being not printed in the repr, with default dtyps varying according to the OS. The tests show that the concerned dtypes are `int32` (for the Windows CI) and `int64` (for Ubuntu and macOS CIs). Using `uint64` should fix both the varying size and the varying numpy array repr. ~~- [ ] Closes #xxxx~~ - [x] Tests added ~~- [ ] User visible changes (including notable bug fixes) are documented in `whats-new.rst`~~ ~~- [ ] New functions/methods are listed in `api.rst`~~ ","{""url"": ""https://api.github.com/repos/pydata/xarray/issues/8719/reactions"", ""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,,13221727,pull