Skip to content

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

Closed

Activity

  1. heliang666s commented on Jul 1, 2025

    @heliang666s
    Contributor

    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.

  2. StanFromIreland commented on Jul 1, 2025

    @StanFromIreland
  3. brianschubert commented on Jul 1, 2025

    @brianschubert
    Contributor

    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)
  4. sobolevn commented on Jul 1, 2025

    @sobolevn
    Member

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

  5. skirpichev commented on Jul 1, 2025

    @skirpichev
    Member

    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.

  6. StanFromIreland commented on Jul 1, 2025

    @StanFromIreland
    Member

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

  7. added a commit that references this issue on Jul 1, 2025
  8. added 2 commits that reference this issue on Jul 1, 2025
  9. added 2 commits that reference this issue on Jul 1, 2025
  10. terryjreedy commented on Jul 1, 2025

    @terryjreedy
    Member

    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.

  11. skirpichev commented on Jul 1, 2025

    @skirpichev
    Member

    we change the doc to avoid breaking possible existing uses

    JFR, I failed to find anything in public.

  12. added a commit that references this issue on Jul 11, 2025
  13. added a commit that references this issue on Jul 12, 2025
  14. added a commit that references this issue on Jul 13, 2025
  15. added a commit that references this issue on Aug 4, 2025
  16. added a commit that references this issue on Aug 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsDocumentation in the Doc direasystdlibStandard Library Python modules in the Lib/ directory

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions