Yves Delley

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

> it is possible to use `pint` + `xarray` without `pint-xarray` I'll have to process that. I'm wondering why one should be using `pint-xarray` in the first place then. I'll...

By modifying global state at import time, the behaviour of my program depends on if `pint-xarray` is imported or not - independent of if the code importing `pint-xarray` is ever...

Of course, the fix in our code wouldn't be particularly difficult. One can argue that any generic code dealing with a pint quantity today will have to be prepared for...

I'm again very much tempted discard `pint-xarray` completely because of the tons of things that break because of the `force_ndarray_like = True`. `pandas` is basically broken with this setting. I...

It's just that: Requiring a change to a global setting make `pint-xarray` a bad player, like a library that only works when the operating system is set to the `C`-locale...

The workflows will require some approval before we get CI feedback...

> So arguably the root problem here is that pint is playing badly in the ecosystem by providing an array-like class which although it purports to be a "duck array"...

I also hit this one. For me, one classic use-case of `__init_subclass__` is for registering sub-classes in some kind of registry, e.g. for deserialisation given some kind of type-key. However,...

I was able to reproduce the same behaviour in JupyterLab, basically on first try on a notebook cell that had shown the same behaviour right before in the classical notebook...