hgrecco / pint-pandas

Pandas support for pint
Other
169 stars 42 forks source link

PintArray doesn't play nice with other Registries #136

Closed MichaelTiemannOSC closed 1 year ago

MichaelTiemannOSC commented 1 year ago

I'm trying to use the openscmunits registry (which has units from the energy/environment world I care about). I abbreviate my Quanity Q:

from pint import get_application_registry
from pint_pandas import PintArray

ureg = get_application_registry()

Q_ = ureg.Quantity
M_ = ureg.Measurement
PA_ = PintArray

I'm using the latest development versions of Pint and Pint-Pandas. I've found that when I create a Quantity from my registry, let's call that value X, then isinstance(X, pint.Quantity) fails. But str(type(X)) == str(Quantity) succeeds.

I had done a pretty thorough scrubbing my own code to change away from using instance, when I discover that PintPandas relies on that, too.

Should I fix the problem this way:

# After initializations are complete...
pint.Quantity = Q_

And be done with it? How should Pint-Pandas (and Pint for that matter) really maintain the value of Quanity (and _Quantity) once set_application_registry() has been called?

I have been able to re-arrange my file import rules so that nothing imports pint_pandas before the pint/openscm-units battle is fought and pint.Quantity is safely updated to the value of Quantity from openscm-units. But that strikes me as fragile.

andyr0id commented 1 year ago

Hey @MichaelTiemannOSC did you try this:

import pint_pandas
pint_pandas.PintType.ureg = get_application_registry()

It's way down in cell 29 of the example notebook.

MichaelTiemannOSC commented 1 year ago

I have learned that once the registries are agreed, pint.Quantity gives a good answer, but importing Quantity from pint is a Bad Idea because without great care, Quantity's value does not stay connected to pint.Quantity and isinstance(x, Quantity) will give a surprising result, whereas isinstance(x, pint.Quantity) gives an expected result.