gh-130662: make Fraction's formatting more compatible wrt float's

[skirpichev]

• Issue: format(Fraction(1, 3), '.016f') raises ValueError #130662

[skirpichev]

CC @ericvsmith per experts index

[serhiy-storchaka]

LGTM.

I have some minor suggestions for tests.

[gvanrossum]

Note that there's another inconsistency between float and Fraction.

x = 1/3
f"{x:_>010f}"  # '__3.140000', ignores the zero-pad
x = Fraction(1, 3)
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    f"{x:_>010f}"
      ^^^^^^^^^^
  File "/Users/guido/cpython/Lib/fractions.py", line 600, in __format__
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Invalid format specifier '_>010f' for object of type 'Fraction'

So we still fail the goal of Fraction supporting everything that float does. Since Fraction actually is more strict (which is the way of the future) aren't we fixing this the wrong way?

[skirpichev]

Here is implementation pr, for context: #100161

The ValueError raised in case both alignment (and the fill character) and zero padding are specified on the ground "refuse the temptation to guess". In principle, it's not hard to reproduce float's behavior (zero padding is ignored if the fill character is specified). Though, maybe it's better to align this with the Fraction instead. Probably, it's a separate issue. Edit: #130716

Few another incompatibilities: #130664

[gvanrossum]

As happens occasionally, the docs are out of sync with the implementation, and we should respond by updating the docs, not the code. IMO.

[skirpichev]

The problem is that the stdlib has several beasts (Decimal and Fraction), that have slightly different implementations of new-style formatting. IMO, documenting all these differences will make documentation much less readable.

Also, it's less obvious to which convention should follow external modules, like the mpmath or the gmpy2.

[gvanrossum]

Okay, I will leave it to more active core devs to sort out.

[skirpichev]

Alternative pr: #130717