Thanks @caenrigen

Unit Test Results

6 files           6 suites   51m 7s :stopwatch: 16 290 tests 14 551 :heavy_check_mark: 1 739 :zzz: 0 :x: 90 936 runs  82 738 :heavy_check_mark: 8 198 :zzz: 0 :x:

Results for commit add9b1ae.

:recycle: This comment has been updated with latest results.

That UnitStrippedWarning might be the same one that I apparently forgot to fix in #5561? I need to look more closely...

I would appreciate a lot if we keep the scope of this PR to what I have contributed so far, I am running out of bandwidth in the project I am involved and won't be able to add much more to this PR.

Thank you very much for your work so far @caenrigen ! We can take this PR from here :)

Hi @Illviljan @keewis,

I have added tests and marked them as xfail

Accoriding to pytest docs

A skip means that you expect your test to pass only if some conditions are met, otherwise pytest should skip running the test altogether. Common examples are skipping windows-only tests on non-windows platforms, or skipping tests that depend on an external resource which is not available at the moment (for example a database).

An xfail means that you expect a test to fail for some reason. A common example is a test for a feature not yet implemented, or a bug not yet fixed. When a test passes despite being expected to fail (marked with pytest.mark.xfail), it’s an xpass and will be reported in the test summary.

This case seems exactly what xfail is meant for. But feel free to change this.

Do the slice plots work with non-dimension coordinates? If so, we should maybe add a test with pint for that, too: units in non-dimension coordinates are not stripped.

It seems so, but it raises a pint warning despite the code producing the intended figure:

```python import xarray as xr import numpy as np import matplotlib.pyplot as plt import pytest pint = pytest.importorskip("pint") unit_registry = pint.UnitRegistry(force_ndarray=True)

coord_unit, coord_attrs = (unit_registry.m, {})

def test_units_in_slice_line_plot_labels_isel(): arr = xr.DataArray( name="var_a", data=np.array([[1, 2], [3, 4]]), coords=dict( a=("x", np.array([5, 6]) * coord_unit, coord_attrs), b=("y", np.array([7, 8])), ), dims=("x", "y"), ) arr.isel(x=0).plot(marker="o") assert plt.gca().get_title() == "a = 5 [meter]" return arr

test_units_in_slice_line_plot_labels_isel() ```

I would appreciate a lot if we keep the scope of this PR to what I have contributed so far, I am running out of bandwidth in the project I am involved and won't be able to add much more to this PR.

Kind regards, Victor

but let it xfail for now with a nice explanation

yes, let's wait until the index refactor has progressed a bit more. I'd skip it, though: we know that the test will fail right now, so there's no point in running the test (and it's also what all the other tests do, so it's better to be consistent).

Do the slice plots work with non-dimension coordinates? If so, we should maybe add a test with pint for that, too: units in non-dimension coordinates are not stripped.

I thought a little about the pint issue and for dataarrays you can probably modify the attrs dict around here: https://github.com/pydata/xarray/blob/07de257c5884df49335496ee6347fb633a7c302c/xarray/core/dataarray.py#L133

But I'm not sure it's worth the effort considering the explicit indexes rework is ongoing, #5692, and that should hopefully allow pint quantities on coords.

I'd suggest adding a pint test anyway, but let it xfail for now with a nice explanation. The TODO comment might get lost in the sea of code.

That's rather annoying that the pint units are dropped: python arr = xr.DataArray( name="var_a", data=np.array([[1, 2], [3, 4]]), # TODO make coord a Quantity once unit-aware indexes supported coords=dict( a=("a", pint.Quantity(np.array([5, 6]), "s")), b=("b", np.array([7, 8]), {"unit": "s"}), ), dims=("a", "b"), ) C:\Users\J.W\Documents\GitHub\xarray\xarray\core\utils.py:118: UnitStrippedWarning: The unit of the quantity is stripped when downcasting to ndarray. index = pd.Index(np.asarray(array), **kwargs) I think xarray could've at least moved the pint unit string to arr.a.attrs["units"] before downcasting it to ndarrays.

Just checked and this cannot be tested for pint units, there is already a comment in there explaining this:

```python

TODO make coord a Quantity once unit-aware indexes supported"

``` Since the slice units come from a coordinate these units can't be pint units (at least not yet).

I added a new test for the units in the title of a slice line plot, also added the same comment about pint units.

Who should I ping for the PR approval?

This is great, thanks @caenrigen !

It just needs a couple of tests - ideally one for basic behaviour like you've shown in your example (which should probably live here), and another checking that it works with pint units like we added in #5561.

Hi @TomNicholas!

Thank you for the input and guidance, will work on adding the tests 🙂

Cheers