Skip to content

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

Closed
Closed
format(Fraction(1, 3), '.016f') raises ValueError#130662
Labels
3.14bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

Description

@skirpichev
skirpichev
opened on Feb 28, 2025

Bug report

Bug description:

c.f.

>>> format(float(Fraction(1, 3)), '.016f')
'0.3333333333333333'

Looking on docs, I think that float formatting better conforms to the specification.

Similar issue is valid for the width:

>>> format(float(Fraction(1, 3)), '0030.016f')
'0000000000000.3333333333333333'
>>> format(Fraction(1, 3), '0030.016f')
Traceback (most recent call last):
  File "<python-input-3>", line 1, in <module>
    format(Fraction(1, 3), '0030.016f')
    ~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/fractions.py", line 577, in __format__
    raise ValueError(
    ...<2 lines>...
    )
ValueError: Invalid format specifier '0030.016f' for object of type 'Fraction'

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

Activity

  1. skirpichev
    added
    stdlibStandard Library Python modules in the Lib/ directory
    type-bugAn unexpected behavior, bug, or error
    on Feb 28, 2025
  2. skirpichev
    self-assigned this
    on Feb 28, 2025
  3. skirpichev
    added a commit that references this issue on Feb 28, 2025

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

    caefd01

  4. skirpichev commented on Feb 28, 2025

    @skirpichev
    skirpichev
    on Feb 28, 2025
    MemberAuthor

    CC @mdickinson

    BTW, I like more strict formatting rules for Fraction's. Maybe we should keep them, then this should be documented as now docs says: "If the format_spec format specification string ends with one of the presentation types 'e', 'E', 'f', 'F', 'g', 'G' or '%' then formatting follows the rules outlined for the float type in the Format Specification Mini-Language section." Adding more strict processing of width and precision for floats - probably will be too severe compatibility break.

    PR is ready for review: #130663

  5. gvanrossum commented on Feb 28, 2025

    @gvanrossum
    gvanrossum
    on Feb 28, 2025
    Member

    I'm not crazy about the proposed fix. It's harmless, but it perpetuates the questionable support for meaningless extra leading zeros.

    I agree we can't tighten float's formatting language, it's not worth breaking working code over.

    As far as the docs, maybe we can change the float docs to disallow the redundant leading zeros and explain in a note that CPython does support those for backwards compatibility reasons, but only for float, not for Fraction? Or otherwise mention the difference in the Fraction docs.

  6. skirpichev commented on Feb 28, 2025

    @skirpichev
    skirpichev
    on Feb 28, 2025
    MemberAuthor

    I agree we can't tighten float's formatting language, it's not worth breaking working code over.

    Maybe we can. I doubt someone rely on this "feature". Thus, deprecating this behavior will not affect too much code.

    On another hand, it seems that more strict processing - slightly complicates parsing in C (get_integer() helper) and the grammar rules. So, maybe those zeros aren't a big problem: it's easy to support them in the fractions module, see pr. Support this - also not a big problem for external modules, see the mpmath issue.

    maybe we can change the float docs to disallow the redundant leading zeros and explain in a note that CPython does support those for backwards compatibility reasons, but only for float, not for Fraction? Or otherwise mention the difference in the Fraction docs.

    Formatting docs already (IMO) big and complex. I would prefer to avoid adding more special cases (there is already float vs Decimal differences, etc).

    Maybe we could just document more strict requirements for width/precision and soft-deprecate old behavior in WhatsNew?

  7. serhiy-storchaka commented on Feb 28, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on Feb 28, 2025
    Member

    I think it is better to allow leading zeroes in "width" and "precision" in the Fraction format. The current specification allows leading zeroes, forbidding them would make it even more complex. AFAIK, leading zeroes are allowed in all other programming languages. So forbidding them would complicate the documentation, the implementation, will create unnecessary difference from other programming languages.

  8. gvanrossum commented on Feb 28, 2025

    @gvanrossum
    gvanrossum
    on Feb 28, 2025
    Member

    I note that Python numbers cannot have leading zeros (to avoid confusion with octal notation in C, C++ and in ancient Python).

    But as the simplest (and fully backwards compatible) solution is to allow redundant leading zeros for Fraction, let's just do that.

    For consistency I would also make the same change in _GENERAL_FORMAT_SPECIFICATION_MATCHER.

  9. skirpichev commented on Mar 1, 2025

    @skirpichev
    skirpichev
    on Mar 1, 2025
    MemberAuthor

    I note that Python numbers cannot have leading zeros (to avoid confusion with octal notation in C, C++ and in ancient Python).

    Note, that in the given context we have only decimal notation.

    BTW, Decimal's seems to be partially affected by this issue (width processing):

    >>> f"{Decimal(1.25):0010f}"
Traceback (most recent call last):
  File "<python-input-9>", line 1, in <module>
    f"{Decimal(1.25):0010f}"
      ^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid format string
>>> f"{Decimal(1.25):.010f}"
'1.2500000000'

  10. gvanrossum commented on Mar 1, 2025

    @gvanrossum
    gvanrossum
    on Mar 1, 2025
    Member

    Yeah, so I am now against “fixing” this. It is easy for users to avoid the issue: don’t use redundant leading zeros.

    If there is concern about the docs, let’s change the float docs to no longer promise support for redundant leading zeros. Then users who discover that they work can file issues about getting float fixed, to which we can respond that it is an accidental historic bug that they are supported, and we recommend not using that, it we are reluctant to fix it for fear of unnecessary breaking working code.

  11. skirpichev
    added a commit that references this issue on Mar 1, 2025

    pythongh-130662: refine width/precision specification in format-spec

    3bb31f5

  12. serhiy-storchaka commented on Mar 1, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on Mar 1, 2025
    Member

    I suspect that the pattern for width and precision in _FLOAT_FORMAT_SPECIFICATION_MATCHER was just copied from the pattern for width in _GENERAL_FORMAT_SPECIFICATION_MATCHER, as it was the nearest place. There was reason for not supporting leading zeroes in _GENERAL_FORMAT_SPECIFICATION_MATCHER (the zeropad flag is not supported), but that does not apply for _FLOAT_FORMAT_SPECIFICATION_MATCHER.

  13. skirpichev commented on Mar 1, 2025

    @skirpichev
    skirpichev
    on Mar 1, 2025
    MemberAuthor

    let’s change the float docs to no longer promise support for redundant leading zeros.

    Alternative pr: #130717 (docs only)

  14. gvanrossum commented on Mar 1, 2025

    @gvanrossum
    gvanrossum
    on Mar 1, 2025
    Member

    Okay, this is much more of a quagmire than I had assumed. In the end I don't care enough about this issue. I will withdraw from the discussion and let you all decide (you might simply vote on it).

  15. 22 remaining items

  16. serhiy-storchaka commented on Jun 2, 2025

    @serhiy-storchaka
    serhiy-storchaka
    on Jun 2, 2025
    Member

    Something related issues: accepting ASCII-only or non-ASCII digits and interpreting the single 0 as the zero-fill flag or the width.

  17. skirpichev commented on Jun 2, 2025

    @skirpichev
    skirpichev
    on Jun 2, 2025
    MemberAuthor

    #135025 is related

  18. bkeryan
    added 2 commits that reference this issue on Jun 27, 2025

    bintime: Fix TimeDelta.__repr__ formatting errors with PyPy

    06fd6b3

    nitypes: Enable testing with PyPy (#134)

    c367804
  19. miss-islington
    added 2 commits that reference this issue on Jul 7, 2025

    pythongh-130662: Accept leading zeros in precision/width for Fraction…

    c53c357

    pythongh-130662: Accept leading zeros in precision/width for Decimal'…

    19a5631
  20. hugovk
    added 2 commits that reference this issue on Jul 7, 2025

    [3.14] gh-130662: Accept leading zeros in precision/width for Fractio…

    b2a2f03

    [3.14] gh-130662: Accept leading zeros in precision/width for Decimal…

    f87578f
  21. skirpichev
    closed this as completedon Jul 7, 2025
  22. Pranjal095
    added 2 commits that reference this issue on Jul 12, 2025

    pythongh-130662: Accept leading zeros in precision/width for Fraction…

    a14ca96

    pythongh-130662: Accept leading zeros in precision/width for Decimal'…

    cd79e61
  23. taegyunkim
    added 2 commits that reference this issue on Aug 4, 2025

    pythongh-130662: Accept leading zeros in precision/width for Fraction…

    1207ea5

    pythongh-130662: Accept leading zeros in precision/width for Decimal'…

    f3edd38
  24. Agent-Hellboy
    added 2 commits that reference this issue on Aug 19, 2025

    pythongh-130662: Accept leading zeros in precision/width for Fraction…

    0624b1e

    pythongh-130662: Accept leading zeros in precision/width for Decimal'…

    333591c
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

    3.14bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions