`fractions.Fraction.from_float` parameter `f` is documented as `flt`

[dscorbett]

Documentation

fractions.Fraction.from_float’s parameter is documented as flt, but it is actually named f.

Linked PRs

• gh-136169: Update parameter name in fractions.from_float method #136172
• [3.14] gh-136169: Update parameter name in fractions.from_float method (GH-136172) #136174
• [3.13] gh-136169: Update parameter name in fractions.from_float method (GH-136172) #136175

[heliang666s]

thank you, but In the future, you don't need to make issues for small docs typos, you can give a pr to resolve it.

[StanFromIreland]

If there is a desire for them to match, then the source should be updated since flt is more descriptive and consistent IMO.

cpython/Lib/fractions.py

Line 332 in 0e19db6

def from_float(cls, f):

For reference,

cpython/Lib/fractions.py

Line 346 in 0e19db6

def from_decimal(cls, dec):

[brianschubert]

the source should be updated

I'm not sure what's been done in similar situations, but renaming the parameter has a risk of breaking backwards compatibility. There could be code that passes f as a keyword argument:

>>> fractions.Fraction.from_float(f=123.456)
Fraction(8687443681197687, 70368744177664)

[sobolevn]

We can't update the source code, because it is the named param. Code like .from_float(f=1.0) would break.

[skirpichev]

I suspect that argument names are not expected to be a part of the module API. (But see #101817 .)

If there is a desire for them to match, then the source should be updated since flt is more descriptive and consistent IMO.

On a ground of backward compatibility I think that simple patch (flt->f renaming) in sphinx docs is fine.

Though, we can adjust the code instead. I think that compatibility break is rather theoretical (e.g. Fraction.from_float(f=something) is much more slow). But I suggest first do some research to find such use cases e.g. on the GitHub.

[StanFromIreland]

I withdraw my proposal, renaming the doc is much easier so +1 on that.