Pretty Printing Fractional Exponential Units about pint HOT 3 OPEN

an opportunity to both fix the bug and enhance Pint.

This is always a good combination!

The problem as I see it is that 3/2 for Python 3 is a float, not a fraction. To have a fraction we will need to do something like:

>>> from fractions import Fraction
>>> q  = ureg.meter ** Fraction(3,2)

which, by the way, is now also converted to float internally:

>>> q
<Quantity(1.0, 'meter ** 1.5')>

I see two ways to implement your suggestion, and maybe we want to implement both.

1.- Change the formatting part

We can get the exponents and try to convert them from float to fraction.

>>> Fraction.from_float(1.5)
Fraction(3, 2)

The good part: it will be transparent to the user.
The bad part: it will add some complexity to the formatting code to decide when we want to do this.

2.- Allow any scalar numeric type for the exponents

The good part: will allow the user to make some calculations more accurate. In fact, this is why the implementation Pi Theorem works so well in Pint: we use Fraction as the type to avoid precision problems associated with floats.
The bad part: User will have to define the quantity with a fractional exponent so it could be nicely printed. Additionally, when you give the freedom to use any scalar numerical type you might hit some errors like this:

>>> decimal.Decimal(0.1) + 1.
Traceback (most recent call last):
[...]
TypeError: unsupported operand type(s) for +: 'Decimal' and 'float'

We will need to guard for those.

As I said, maybe the way is to implement both.

from pint.

@hgrecco

I think to move forward we need to maybe only allow integer or Fraction as power in units.
This is critical if we want to allow fractional exponent units.

Operations on integer & Fraction are easily supported using python.
Other numerical type could be casted to Fraction.

I think it deserves an issue on its own to work on.

About this issue, we can easily support it if we encounter Fraction, it will display '3/2' and we can add pretty print after that in the dedicated function.

from pint.

I do agree that we need an issue on its own. In particular, I think it is worth discussing if we should enable a plugable architecture (like non_int_type or similar)

from pint.