gh-136169: Update parameter name in fractions.from_float method

[lazorikv]

• Issue: fractions.Fraction.from_float parameter f is documented as flt #136169

---

📚 Documentation preview 📚: https://cpython-previews--136172.org.readthedocs.build/

[sobolevn]

Thanks!

[miss-islington-app]

Thanks @lazorikv for the PR, and @sobolevn for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-136174 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-136175 is a backport of this pull request to the 3.13 branch.

[ZeroIntensity]

If anyone is interested in a follow-up, decimal has a similar method, but the issue there is that Decimal.from_float doesn't accept kwargs at all, so from_float(f=...) breaks.

[skirpichev]

but the issue there is that Decimal.from_float doesn't accept kwargs at all

C extension method - doesn't, but for pure-Python case - does:

>>> import inspect, _pydecimal, _decimal
>>> inspect.signature(_pydecimal.Decimal.from_float)
<Signature (f)>
>>> inspect.signature(_decimal.Decimal.from_float)
<Signature (f, /)>

As explained in the issue thread, the argument name is not a part of API. IMO, this pr makes docs a little worse.

from_float(f=...) breaks

Have you find some such code?

[ZeroIntensity]

C extension method - doesn't, but for pure-Python case - does:

Ugh, yuck. I'm not sure then. It's probably safest to force the Python implementation to be positional-only.

[skirpichev]

There is a long list of issues, related to pydecimal/decimal incompatibilities (mostly closed), e.g. #117056.

It's probably safest to force the Python implementation to be positional-only.

I'm not sure if it does make sense to maintain it. We have a mature C extension and, IMO, the decimal module can be optional.

[StanFromIreland]

@terryjreedy This has already been backported see: 3.14, 3.13