awesome work @keewis !

Phew thanks a lot @keewis!

Great! Quite an effort @keewis —thank you!

I would think so, too. Go ahead.

Edit: seems like other PRs have the same problem, see #3409

I think these tests are unrelated and we can merge?

```python

=================================== FAILURES =================================== ____ testdatetime_reduce[False] ______

dask = False

@arm_xfail
@pytest.mark.parametrize("dask", [False, True])
def test_datetime_reduce(dask):
    time = np.array(pd.date_range("15/12/1999", periods=11))
    time[8:11] = np.nan
    da = DataArray(np.linspace(0, 365, num=11), dims="time", coords={"time": time})

    if dask and has_dask:
        chunks = {"time": 5}
        da = da.chunk(chunks)

    actual = da["time"].mean()

  assert not pd.isnull(actual)

E AssertionError: assert not True E + where True = <function isna at 0x7fcbdefdbae8>(<xarray.DataArray 'time' ()>\narray('NaT', dtype='datetime64[ns]')) E + where <function isna at 0x7fcbdefdbae8> = pd.isnull

xarray/tests/test_duck_array_ops.py:288: AssertionError ____ test_datetime_reduce[True] ______

dask = True

@arm_xfail
@pytest.mark.parametrize("dask", [False, True])
def test_datetime_reduce(dask):
    time = np.array(pd.date_range("15/12/1999", periods=11))
    time[8:11] = np.nan
    da = DataArray(np.linspace(0, 365, num=11), dims="time", coords={"time": time})

    if dask and has_dask:
        chunks = {"time": 5}
        da = da.chunk(chunks)

    actual = da["time"].mean()

  assert not pd.isnull(actual)

E AssertionError: assert not True E + where True = <function isna at 0x7fcbdefdbae8>(<xarray.DataArray 'time' ()>\narray('NaT', dtype='datetime64[ns]')) E + where <function isna at 0x7fcbdefdbae8> = pd.isnull ```

done

Also please move the what's new blob from 0.14.0 to 0.14.1

whatsnew.rst: ``` - Added integration tests against pint https://pint.readthedocs.io/_.

.. note::

At the moment of writing, these tests *as well as the ability to use pint in general*
require `a highly experimental version of pint
<https://github.com/andrewgsavage/pint/pull/6>`_ (install with 
``pip install git+https://github.com/andrewgsavage/pint.git@refs/pull/6/head)``.
Even with it, interaction with non-numpy array libraries, e.g. dask or sparse, is broken.

installing.rst - pint <https://pint.readthedocs.io/>_: for units of measure.

.. note::

At the moment of writing, xarray requires a `highly experimental version of pint 
<https://github.com/andrewgsavage/pint/pull/6>`_ (install with
``pip install git+https://github.com/andrewgsavage/pint.git@refs/pull/6/head)``.
Even with it, interaction with non-numpy array libraries, e.g. dask or sparse, is broken.

```

I don't really know what to write about

readers will be much more interested in what they can actually do with pint

because a feature list seems to be a bit too long to me.

re installing.rst: is adding (experimental) enough, or should the line with pip also appear there?

@keewis looks good. Also something equivalent in installing.rst on the line that mentions pint, please

I have been using a PR to hgrecco/pint#764 because that has been the version that had the most tests pass. Is that okay, or should I use the original PR instead?

So something like this?

Added integration tests against pint <https://pint.readthedocs.io/>_. Note that these tests currently require a special version of pint <https://github.com/andrewgsavage/pint/pull/6> (install with pip install git+https://github.com/andrewgsavage/pint.git@refs/pull/6/head) to run and are otherwise skipped. Also note that at the moment of writing, there are issues when pint interacts with non-numpy array libraries, e.g. dask or sparse.

Edit: this one works

Added integration tests against pint <https://pint.readthedocs.io/>_. Note that these tests currently require a special version of pint to run and are otherwise skipped. Also note that at the moment of writing, there are issues when pint interacts with non-numpy array libraries, e.g. dask or sparse.

(remove emphasis in actual version)

readers will be much more interested in what they can actually do with pint

👍 , let's add a sentence

@keewis maybe you could clarify where to find this special version and how to get it (pip install https+git://...)? Also I think readers will be much more interested in what they can actually do with pint and what they can't, as opposed to what CI tests we're running.

what do you think of this for whats-new.rst?

Added integration tests against pint <https://pint.readthedocs.io/>_. Note that these tests currently require a special version of pint to run. Also note that at the moment of writing, there are issues when pint interacts with non-numpy array libraries, e.g. dask or sparse.

@keewis could you tweak whatsnew.rst and installing.rst to set the expectations (very low) for people using the current latest available release of pint?

OK great! @crusaderky any final thoughts? Anyone else?

I assumed this to be the same as datetime, which means object labels instead of strings. So now only the top-level functions and dataset are missing.

👍

I updated the PR so that all the DataArray methods I found in the docs have a test, the only exception is to_unstacked_dataset where I don't know what the result should look like: Consider ```python

data = [[0, 10, 20], [30, 40, 50]] x = [0, 1] y = [0, 1, 2] arr = xr.DataArray(data=data, coords={"x": x, "y": y}, dims=("x", "y")) arr.stack(z=("x", "y")).to_unstacked_dataset(dim="z") <xarray.Dataset> Dimensions: (y: 3) Coordinates: * y (y) int64 0 1 2 Data variables: 0 (y) int64 0 10 20 1 (y) int64 30 40 50 `` and supposing that indexes keep the units, what should the result of the above, but with units onx`, look like?

Edit: I assumed this to be the same as datetime, which means object labels instead of strings. So now only the top-level functions and dataset are missing.

I'd like to leave these two and replacing assert_equal_with_units with either xarray.testing.assert_identical or xarray.testing.assert_allclose or a combination of both to new PRs, so now this should be ready for review.

Fixed CI, What's New, and Installing doc

that's fine with me. I resolved the merge conflicts (along with other stuff), so only whats-new.rst and sorting out what is to be done in new PRs are left to do.

@keewis - I'm wondering if it would be worth merging this in its current state and leaving the rest of the checklist for a follow up PR? No harm in working incrementally on this. We just need to add a note in whats-new.rst and resolve a few merge conflicts. Thoughts?

In general we've tried to make identical as exactly identical, including types etc, so I think different units would return False there

I'm currently working on the tests for the comparison methods (DataArray.equals, DataArray.identical and DataArray.broadcast_equals) and I'm trying to figure out what equals and identical return. equals is easy: just make sure the wrapped quantities are equal. identical is a stricter version of equals, so I was wondering whether it should also return False if the values are equal, but in compatible units (like 10 cm and 0.1 m)? Any thoughts on this?

I'm not sure where to put this, so I'll post this here.

While working on the numpy methods part and using any of the pint versions implement __array_function__ (hgrecco/pint#764 and andrewgsavage/pint#6) , I encountered the following: ```python

array = np.array([1.3, 3.1, 7.5]) array.searchsorted(2.4) 1 (array * ureg.m).searchsorted(2.4 * ureg.m) Traceback (most recent call last): File "<stdin>", line 1, in <module> File ".../pint/quantity.py", line 1548, in searchsorted raise DimensionalityError('dimensionless', self._units) pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter' (array * ureg.m).searchsorted(2.4) <Traceback> pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter' (array * ureg.m).searchsorted(2.4 * ureg.s) <Traceback> pint.errors.DimensionalityError: Cannot convert from 'dimensionless' to 'meter' I believe that is because in `BaseQuantity.searchsorted`, `self.__class__` is used to check the type, which may be either `QuantitySequence` or `QuantityScalar`. If `self` is a sequence and a scalar is passed to the method, this fails. To fix this, replacing `self.__class__` with `BaseQuantity` seems to work.python np.searchsorted(array * ureg.m, 2.4 * ureg.m) <Quantity(1, 'meter')> np.searchsorted(array * ureg.m, 2.4) <Quantity(1, 'meter')> np.searchsorted(array * ureg.m, 2.4 * ureg.s) <Traceback> pint.errors.DimensionalityError: Cannot convert from 'second' ([time]) to 'meter' ([length]) `` I don't know what to do here (using the code from andrewgsavage/pint#6 I tried movingsearchsortedinto the same category asisclose` -- this seems to work partially, but passing non-quantities is still allowed), but the result should be indices and incompatible units (or no unit at all) should raise an error.

Both the method and the function work fine with current master.

me hitting that issue is probably a bug in how xr.Variable handles np.full_like (the unit gets stripped), so no worries.

I'm not sure whether that belongs into hgrecco/pint#882, so I'll ask this here: In the case of full_like with other being a ndarray and fill_value having a unit, numpy complains about np.copyto not being implemented for this type of operation: ```python

np.full_like(np.arange(10), fill_value=1 * ureg.m) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<array_function internals>", line 6, in full_like File ".../lib/python3.7/site-packages/numpy/core/numeric.py", line 401, in full_like multiarray.copyto(res, fill_value, casting='unsafe') File "<array_function internals>", line 6, in copyto TypeError: no implementation found for 'numpy.copyto' on types that implement array_function: [<class 'numpy.ndarray'>, <class 'pint.quantity.build_quantity_class.\<locals>.QuantityScalar'>]

yeah, well, I can create that index outside of pytest with python pd.Index(list(np.arange(10) * ureg.m)) so the performance is that of an index on a python list. How that happens is beyond me, though.

About the indexing: this might have been accidental (or a bug in pandas) and is probably a bad idea, but do you think it might be worth to somehow actively trigger this behavior in pd.Index for pint arrays (and possibly others) until the index refactoring from https://github.com/pydata/xarray/issues/1603#issuecomment-511126208 is done?

I like your approach because it avoids all those issues, but stripping the units might be a surprise. Then again, what does a function named *_like promise? From the docs, it seems that only shape and dtype are guaranteed, so the question is whether or not the unit is part of the data or part of the type?

I tried adding tests for zeros_like, ones_like and full_like, but I'm not sure what the expected result should look like, at least for the last one. I would assume zeros_like and ones_like return a quantity with the same unit as other, but what is the unit for full_like? The unit of other, or the unit of fill_value? Also, what happens if either of them has no unit, or both have units that are incompatible with each other?

After digging a little bit more, I think the reason why filterwarnings() made me think the indexing tests pass is that when a UnitStrippedWarning is raised (mostly after accessing __array_struct__), the filter replaces it with a DimensionalityError, complaining that it can't convert to dimensionless. This confuses me: when directly accessing an attribute starting with __array_, pytest correctly points out the raised UnitStrippedWarning.

Also, it seems that because DimensionalityError inherits from ValueError, the type of the parameter index of convert_label_indexer is changed from Int64Index to Index (which has dtype="object" ), which does not cast to ndarray, thus keeping the unit information and causing sel() to correctly raise a KeyError. I can reproduce both behaviors using ```python import numpy as np import pytest import xarray as xr

pint = pytest.importorskip("pint") ureg = pint.UnitRegistry()

@pytest.mark.xfail def test_indexing_fail(): array = np.linspace(1, 2, 20) * ureg.m x = np.arange(len(array)) * ureg.s data_array = xr.DataArray(data=array, coords={"x": x}, dims=["x"]) with pytest.raises(KeyError): data_array.sel(x=np.array([13, 5, 9]) * ureg.m)

@pytest.mark.filterwarnings("error:::pint[.*]") def test_indexing_pass(): array = np.linspace(1, 2, 20) * ureg.m x = np.arange(len(array)) * ureg.s data_array = xr.DataArray(data=array, coords={"x": x}, dims=["x"]) with pytest.raises(KeyError): data_array.sel(x=np.array([13, 5, 9]) * ureg.m) ``` Note: the only difference between the two is the decorator.

It seems the reason for both the np.median weirdness and the indexing unexpectedly passing is the module level filterwarnings mark. I'm not sure why that happens, but for now I'll remove the module level mark. Also, that means that now all aggregation functions fail for data arrays, so I'll definitely have to add method tests.

np.prod: seems fair, and I don't especially need that function as I have been copying its use from test_sparse.py (though I realize now that there only the method is used). However, using array.prod() works on quantities, so I would expect np.prod to delegate to it. Same with any() and all().

np.median: this also happens in my environment, so you can rule out the environment. Calling it on quantities instead of data arrays works, so the issue is within xarray. Interestingly, outside of pytest: ```python

xr.DataArray(data=np.arange(10).astype(int) * ureg.m).median() <xarray.DataArray ()> <Quantity(4.5, 'meter')> xr.DataArray(data=np.arange(10).astype(int) * ureg.m).median() <xarray.DataArray ()> array(4.5) ``` which seems to be a manifestation of #3241 (which is the reason I now always try different dtypes). I guess that one is not really fixed? Also, would it be better to have a test to check the methods in addition to the numpy functions?

Indexing: when I wrote "indexing works" I meant that my tests for sel(), isel() and loc mostly pass (except from the "calling int / float on scalar results" issue). So when calling sel() and loc with either no units, dimensionless or incompatible units (but existing magnitudes), a KeyError is raised. In the case of both compatible units and existing magnitudes the results are also correct, but scalars trigger the error above. Edit: I have been checking the indexing outside of pytest and there the units are not respected. I have no idea why, but I suspect it is at least related to the problem with np.median. Anyway, what is tested is: ```python

array = np.linspace(5, 10, 20).astype(dtype) * ureg.m x = np.arange(len(array)) * ureg.s data_array = xr.DataArray(data=array, coords={"x": x}, dims=["x"]) with pytest.raises(KeyError): ... data_array.sel(x=[10, 5, 13]) with pytest.raises(KeyError): ... data_array.sel(x=[10, 5, 13] * ureg.dimensionless) with pytest.raises(KeyError): ... data_array.sel(x=[10, 5, 13] * ureg.m)

repr of DataArray fails with DimensionalityError

data_array.sel(x=[10, 5, 13] * ureg.s).data <Quantity([7.63157895 6.31578947 8.42105263], 'meter')> ```

@jthielen: I tried my tests (those that are currently written) with your PR to hgrecco/pint#764. From the ones I have been using, np.prod, np.all and np.any (and also __matmul__, but you seem to be working on that) are missing. The question is, how many of these should be supported? Also, there might be better ways to compare quantities, but if not: would it be possible to implement np.allclose? I have been using a workaround, but it seems pretty fragile to me. You may be aware of this, but np.minimum and np.maximum and probably others similar to these are working strangely, even with plain pint: if both arguments are quantities, equal units are required, but the result is not a quantity. It correctly fails if the second argument is not a quantity, but works silently if only the second argument is a quantity (still, the result is a plain array).

As I'm not too content with it: could someone have a look at the way they are written? If there are any serious problems, it might be easier to correct them now and I can keep them in mind for new tests.

Lastly, a status report: Assuming there are no bugs in my tests and using andrewgsavage/pint#6, there are some issues with np.argmax/np.argmin, np.median, np.sum (and probably np.prod, but that is currently hidden). Indexing (sel, isel and loc) seems to work except if a single value (e.g. 1 * ureg.m) / index is passed.

ah, okay, that makes sense. I will leave the filterwarning since I believe the warning should not be raised, but mark that test as xfail until a released pint version implements __array_function__.

@jthielen: thanks, I will look at these when I have the time.

Could you take a look at the failing test for the DataArray-constructor? It fails because pint emits a UnitStrippedWarning on calling hasattr(data, "__array_function__"), which I believe should not happen (correct me if I'm wrong, though).

Great! This is going to be exciting. Ping here for any questions!

From what is already done, mypy . fails because of pint (this the same as with quantities in #2956). What would I do to fix that?

V easy - add to setup.cfg like other libraries listed there