String magnitude

[gsakkis]

Stumbled on this surprising behavior, can't tell if it's a bug, feature or undefined behavior:

In [1]: from pint import UnitRegistry

In [2]: U = UnitRegistry()

In [3]: "1" * U.volt + "1" * U.volt
Out[3]: '11' <Unit('volt')>

[cpascual]

I see the why this may be surprising, but IMHO it is the only consistent behaviour: when multiplying with a unit, pint just creates a Quantity by wrapping whatever arbitrary object you use as the magnitude, with the given unit without altering or making any assumption about the magnitude object

In this case you are using a string object as your magnitude, and the regular (string) operations are used.

The alternative (pint implicitly casting the magnitude to some numerical value) would necessarily require lots of guesswork and oppinionated decisions by pint (e.g., should it cast to an int, or a float, or decimal or ndarray,...?)

Furthermore, implicit casting would never be able to handle arbitrary custom types: consider, e.g. that you create a custom string type for parsing decimal representations that inherits from str but overwrites the __add__ operator to support decimal sums. If pint decided to implicitly cast strings to floats, that would break your case.

So it is better to follow the zen of python ("better explicit than implicit") and let the user cast the magnitude explicitly if needed before wrapping with pint.

[gsakkis]

I wasn't implying that the correct behavior is implicit casting, I'd expect to get a TypeError or ValueError for non-numeric magnitude. Admittedly what exactly is a number is not well-defined (e.g. see [1], [2], [3]) so it makes sense for pint to avoid dealing with the issue altogether.

[cpascual]

I wasn't implying that the correct behavior is implicit casting

Sorry for assuming it... I was just projecting my own internal thoughts 😅

I'd expect to get a TypeError or ValueError for non-numeric magnitude.

I agree that that would be a better alternative than implicit casting, but still I think that most of my argument remains.

Admittedly what exactly is a number is not well-defined (e.g. see python/mypy#3186, beartype/beartype#66, [3]) so it makes sense for pint to avoid dealing with the issue altogether.

... so I think we agree on the conclusion

PS: one of your links lead me to read this informative and funny rant which I loved 🤓 ... thanks for the links!