Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

numeric formatting overriding default_format in 0.19 #1501

Closed
CagtayFabry opened this issue Apr 5, 2022 · 6 comments · Fixed by #1503
Closed

numeric formatting overriding default_format in 0.19 #1501

CagtayFabry opened this issue Apr 5, 2022 · 6 comments · Fixed by #1503

Comments

@CagtayFabry
Copy link

I noticed that the unit string formatting changed slightly with the new 0.19 release

specifically, when setting a custom default_format on the UnitRegistry the setting is now lost when printing with additional numeric formatting options (e.g. .2f) (see the code below)

is this intended or is there a different way to keep the default unit formatting style?

0.18

import pint
print(f"{pint.__version__=}")
#> pint.__version__='0.18'
ureg = pint.UnitRegistry()
q = ureg.Quantity("1.2345 m")

print(f"{q}")
#> 1.2345 meter
print(f"{q:.2f}")
#> 1.23 meter
print(f"{q:~.2f}")
#> 1.23 m

ureg.default_format = "~"

print(f"{q}")
#> 1.2345 m
print(f"{q:.2f}")
#> 1.23 m <- keeps the unit formatting options
print(f"{q:~.2f}")
#> 1.23 m

0.19

import pint
print(f"{pint.__version__=}")
#> pint.__version__='0.19'
ureg = pint.UnitRegistry()
q = ureg.Quantity("1.2345 m")

print(f"{q}")
#> 1.2345 meter
print(f"{q:.2f}")
#> 1.23 meter
print(f"{q:~.2f}")
#> 1.23 m

ureg.default_format = "~"

print(f"{q}")
#> 1.2345 m
print(f"{q:.2f}")
#> 1.23 meter <- ignores the unit formatting options
print(f"{q:~.2f}")
#> 1.23 m
@keewis
Copy link
Contributor

keewis commented Apr 5, 2022

the behavior you see in 0.18 is the one we want to eventually get to (and it certainly seems much more logical to me), but the one in 0.19 is the one from pint<=0.17 (see #1407).

Arguably, this became a bit confusing because there was such a big delay between the releases while the revert was intended for a quick bugfix release, but the idea is that we do a proper deprecation cycle before enabling the entirely separate formats.

@hgrecco, what do you think about adding a setting to the registry that controls this? That way people can explicitly select which behavior to use, and the deprecation might also become a bit easier.

@hgrecco
Copy link
Owner

hgrecco commented Apr 5, 2022

@keewis I agree with the registry setting. If you think you can make it fast, we can include in 0.19.1 that will fix #1498

@hgrecco
Copy link
Owner

hgrecco commented Apr 6, 2022

@keewis I am ready to release 0.19.1. Do you want to include your patch in this release or in 0.19.2?

@keewis
Copy link
Contributor

keewis commented Apr 6, 2022

not sure. I was planning to investigate this evening, but I can't promise anything. If it's not a lot of work for you to do the release I'd say doing two separate bugfix releases might be worth considering?

@hgrecco
Copy link
Owner

hgrecco commented Apr 6, 2022

agreed!

@CagtayFabry
Copy link
Author

thank you for looking into this so quickly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants