Description
Moving to a separate issue to be able to properly track this.
Why does
pint-xarrayrequirepint.application_registry.force_ndarray_like = Truein the first place? I don't like when my dependencies force me to force something... This has become an issue because that very same setting is incompatible withpint-pandas: hgrecco/pint-pandas#165. Given thatxarraybases onpandas, this seems to be somewhat serious.
Originally posted by @burnpanck in #189 (comment)
The reason is that
xarraydetects a duck array using a certain interface, casting everything that does not satisfy that tonumpyusingnp.asarray. Since python scalars (float,int) don't have thendim,dtypeandshapeproperties (thoughpintdoes defaultndimto0), the result of somenumpyfunctions will be cast, dropping the units.Requiring
force_ndarray_likeavoids that, sincepintwill do the casting beforexarraycan do it. I agree that this feels like a hack, though.
Originally posted by @keewis in #189 (comment)
Hm. I have a feeling that this is again a reason for implementing separate
pint.QuantityArrayandpint.QuantityScalartypes - because IMHOpintshould never respond tonp.asarrayby stripping units.
Either way,
pint-pandasdoes not require it, and managed to get most operations to work without stripping units. There, it is up to the user to make sure that their objects make it intopandasas aPintArray, e.g. by settingforce_ndarray_like = True, or simply by directly building aPintArray. But once the quantity arrays are in, pandas operations do not strip units (at least things improved significantly). Given that, in most cases, users of bothxarrayandpandaswork with arrays anyways, it feels like forcingforce_ndarray_like = Trueon every user is rather harsh. Even more so by doing it at import time - causing an import order dependency!
Originally posted by @burnpanck in #189 (comment)