issues

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 raises an error with message:

arithmetic broadcast is disabled via global option

Unrelated

Also adds a decorator to handle the optional dependency dask_expr

• [ ] 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

:information_source: Companion PR of #8698

Aims to check the consequences of transforming join='exact' aligments into join='strict' ones.

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.

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~~

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~~