You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fractions.Fraction.from_float parameter f is documented as flt #136169
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:
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.
When an argument that can already be passed by keyword (only sometimes true for C-implemented function) is mis-documented, we change the doc to avoid breaking possible existing uses. I checked and F.from_float(f=3.2) returns Fraction(3602879701896397, 1125899906842624). It turns out that since 3.2, from_float and from_decimal are redundant as Fraction() directly accepts either. F(numerator=3.2) (yes, weird) also returns Fraction(3602879701896397, 1125899906842624). Does not matter though.
Activity
heliang666s commentedon Jul 1, 2025
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 commentedon Jul 1, 2025
brianschubert commentedon Jul 1, 2025
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
fas a keyword argument:sobolevn commentedon Jul 1, 2025
We can't update the source code, because it is the named param. Code like
.from_float(f=1.0)would break.skirpichev commentedon Jul 1, 2025
I suspect that argument names are not expected to be a part of the module API. (But see #101817 .)
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 commentedon Jul 1, 2025
I withdraw my proposal, renaming the doc is much easier so +1 on that.
gh-136169: Update parameter name in fractions.from_float method (#136172
pythongh-136169: Update parameter name in fractions.from_float method (…
pythongh-136169: Update parameter name in fractions.from_float method (…
[3.13] gh-136169: Update parameter name in fractions.from_float method (
[3.14] gh-136169: Update parameter name in fractions.from_float method (
terryjreedy commentedon Jul 1, 2025
When an argument that can already be passed by keyword (only sometimes true for C-implemented function) is mis-documented, we change the doc to avoid breaking possible existing uses. I checked and
F.from_float(f=3.2)returnsFraction(3602879701896397, 1125899906842624). It turns out that since 3.2, from_float and from_decimal are redundant as Fraction() directly accepts either.F(numerator=3.2)(yes, weird) also returnsFraction(3602879701896397, 1125899906842624). Does not matter though.skirpichev commentedon Jul 1, 2025
JFR, I failed to find anything in public.
pythongh-136169: Update parameter name in fractions.from_float method (…
pythongh-136169: Update parameter name in fractions.from_float method (…
pythongh-136169: Update parameter name in fractions.from_float method (…
pythongh-136169: Update parameter name in fractions.from_float method (…
pythongh-136169: Update parameter name in fractions.from_float method (…