pint 0.18 does not allow to explicitly override "~" modifier in default_format

[cpascual]

Hi, I see a change in the behavior from pint 0.17 to 0.18 which I think it might be a bug.

Consider the following code:

from pint import UnitRegistry

ureg = UnitRegistry()
q = ureg.Quantity("1m")

print(f"implicit (before): {q}")
print(f"explicit (before): {q:d}")

ureg.default_format = "~"

print(f"implicit (after):  {q}")
print(f"explicit (after):  {q:d}")

With pint <=0.17 I get:

implicit (before): 1 meter
explicit (before): 1 meter
implicit (after):  1 m
explicit (after):  1 meter

With pint 0.18 I get:

implicit (before): 1 meter
explicit (before): 1 meter
implicit (after):  1 m
explicit (after):  1 m

IMHO, the behaviour of 0.17 is the expected one, since the default_format should not affect at all when a explicit format is used.

[keewis]

I was thinking that this is a bug until I remembered that #1371 introduced the concept of "magnitude" and "unit" formatters (it was used before, but not clearly separated). This means that the format string of f"{q:d}" basically is split into ("d", ""), where the Unit format is empty and thus the default from default_format is used (which is also split into magnitude and unit format). If your format was f"{q:dP}" instead, you'd get the expected result (i.e. no ~)

I agree that that's surprising, at least given the current documentation, and I don't think I got any feedback regarding this yet (to be fair, it's pretty well hidden in the code and I forgot to raise it in the PR).

[cpascual]

Thanks @keewis for the quick answer!

Just one thing: you mention using f"{q:dP}", which indeed gives the same output in both 0.17 and 0.18, but it uses the pretty format (this becomes evident if we redefine, e.g., q = ureg.Quantity("1m**2")) which may not be desired.

In order to use the default format one can use f"{q:dD}" , but only in pint>=0.18 (unit format "D" is not supported in pint<=0.17)

Therefore, I agree that it is not a bug, but IMHO it should be listed in the CHANGES file as a "Breaking Change" of 0.18

[keewis]

yes, that's a breaking change that should probably have gone through a deprecation cycle. @hgrecco, @jules-ch, do you have a opinion on this? Should we revert that change in behavior and add a deprecation cycle?

[hgrecco]

I think Pint 0.18 is the correct one, but I do agree this was a breaking change. I would agree on releasing a 0.18.1 in the next days rolling back this and deploying this change in 0.19 What I am not clear exactly what exactly you will revert in the code? Is not this very intertwined with the new formatting code? Would reversion cause a very ugly code?

[keewis]

Would reversion cause a very ugly code?

not at all, we'd need to change three lines:

pint/pint/quantity.py

Lines 397 to 398 in 3df6536

	uspec = extract_custom_flags(spec)
	ustr = format(obj.units, uspec)

would become

    ustr = format(obj.units, spec) 

and

pint/pint/unit.py

Line 83 in 3df6536

spec = spec or extract_custom_flags(self.default_format)

would become

        spec = extract_custom_flags(spec or self.default_format)

(plus the code to issue a DeprecationWarning / FutureWarning?)

It would probably also be good to add an explanation to the formatting docs (if it's not there already?)

[jules-ch]

Sounds good to me, we can issue a new release soon with #1403 too.

+1 on the docs.

[hgrecco]

Let me know when the PRs are ready and I can make the release