Open burnpanck opened 7 months ago
Thanks for opening this @burnpanck .
I notice in tests/test_accessors.py
we also separately set force_ndarray_like=True
That seems odd in that it doesn't fully decouple the tests from the code, and also seems like it might be making this PR misleading by causing tests to pass in the CI that would not work in user code?
Didn't spot that one. However, the tests still pass on my machine. To me, this suggests that force_ndarray_like
is really not needed for any of the core xarray
/pint
interop to work. The only case that has been offered is the automatic coercion of a scalar quantity into a zero-dimensional array in the construction of a DataArray
. But I strongly suggest that we add a test for that if we even want to claim that this is an actual feature.
As I pointed out in https://github.com/xarray-contrib/pint-xarray/issues/216#issuecomment-1854413382, it is possible to use pint
+ xarray
without pint-xarray
, so most of the tests that do check compatibility live in xarray
's test suite (for now, there's the desire to move those tests here once we have a replacement that still does extensive checks of the duck array compatibility).
After changing the unit registry of these tests to have force_ndarray_like=False
107 tests are failing, so clearly this is important for pint
support in xarray
.
it is possible to use
pint
+xarray
withoutpint-xarray
I'll have to process that. I'm wondering why one should be using pint-xarray
in the first place then. I'll try to have a go at reproducing those failing tests in xarray
so I understand better.
pint-xarray
is a glue / convenience package: while it is possible to use (most of) pint
+ xarray
without pint-xarray
, it is not very convenient to do so: creating quantities, converting between them, and serializing back to array + attribute would be very complex otherwise (however, this will change with #163, which will allow having units on indexed coordinates, something that currently is not possible).
pre-commit run --all-files
whats-new.rst