Visitar URL original
Implement __format__ for Fraction · Issue #67790 · python/cpython · GitHub
Skip to content

Implement __format__ for Fraction #67790

Closed
Closed
Implement __format__ for Fraction#67790
Assignees
mdickinson
Labels
stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

Description

@suutari
suutari
mannequin
opened on Mar 7, 2015
BPO 23602
Nosy @rhettinger, @mdickinson, @scoder, @ericvsmith, @ezio-melotti, @skrah, @vadmium, @serhiy-storchaka, @wm75, @skirpichev, @suutari
Files
  • issue23602.patch: Fraction.format implementation, test cases and documentation
  • issue23602v2.patch
  • issue23602v3.patch
  • issue23602v4.patch: Fraction.format implementation, test cases and docs, Decimal.format Py and C API unification with test cases
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/serhiy-storchaka'
closed_at = None
created_at = <Date 2015-03-07.17:06:09.308>
labels = ['type-feature', 'library']
title = 'Implement __format__ for Fraction'
updated_at = <Date 2021-04-23.08:41:52.382>
user = 'https://github.com/suutari'

    bugs.python.org fields:

    activity = <Date 2021-04-23.08:41:52.382>
actor = 'Sergey.Kirpichev'
assignee = 'serhiy.storchaka'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2015-03-07.17:06:09.308>
creator = 'tuomas.suutari'
dependencies = []
files = ['38378', '38394', '38413', '38728']
hgrepos = []
issue_num = 23602
keywords = ['patch']
message_count = 29.0
messages = ['237460', '237461', '237468', '237524', '237525', '237526', '237575', '237579', '237583', '237714', '237715', '238813', '239048', '239056', '239336', '239337', '239338', '239342', '239495', '239498', '239501', '239502', '239503', '239504', '239515', '239594', '239664', '239668', '239733']
nosy_count = 11.0
nosy_names = ['rhettinger', 'mark.dickinson', 'scoder', 'eric.smith', 'ezio.melotti', 'skrah', 'martin.panter', 'serhiy.storchaka', 'wolma', 'Sergey.Kirpichev', 'tuomas.suutari']
pr_nums = []
priority = 'low'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23602'
versions = ['Python 3.5']

    Linked PRs

    Activity

    1. suutari commented on Mar 7, 2015

      @suutari
      suutarimannequin
      on Mar 7, 2015
      MannequinAuthor

      Since Decimal supports __format__, it would be nice that Fraction did too.

    2. suutari
      added
      stdlibStandard Library Python modules in the Lib/ directory
      on Mar 7, 2015

    3. suutari commented on Mar 7, 2015

      @suutari
      suutarimannequin
      on Mar 7, 2015
      MannequinAuthor

      Here's a patch that adds Fraction.__format__ implementation, test cases and documentation.

    4. ezio-melotti
      added
      type-featureA feature request or enhancement
      on Mar 7, 2015

    5. serhiy-storchaka commented on Mar 7, 2015

      @serhiy-storchaka
      serhiy-storchaka
      on Mar 7, 2015
      Member
      >>> from fractions import Fraction as F
>>> format(F(1, 3), '.30f')
'0.333333333333333333333333333300'

    6. suutari commented on Mar 8, 2015

      @suutari
      suutarimannequin
      on Mar 8, 2015
      MannequinAuthor
      Serhiy Storchaka wrote:
>>>> from fractions import Fraction as F
>>>> format(F(1, 3), '.30f')
> '0.333333333333333333333333333300'

      Good catch! I'll try to fix this and add some more test cases.

    7. ericvsmith commented on Mar 8, 2015

      @ericvsmith
      ericvsmith
      on Mar 8, 2015
      Member

      I'm not sure it needs fixing: it follows from the definition of using Decimal(num) / Decimal(denom). Plus, it's controllable with a decimal context:

      >>> from decimal import localcontext
>>> with localcontext() as ctx:
...   ctx.prec = 100
...   format(F(1, 3), '.30f')
...
'0.333333333333333333333333333333'
>>>

      For all of the tests, I suggest using format(value, str) instead of ''.format(value). It more directly tests Fraction.__format__.

      In general I think adding Fraction.__format__ is a good idea, and I think converting to Decimal is reasonable for the specified codes. My only question is what to do when "natively" formatting Fractions themselves. We might want to support field widths, padding, etc.

    8. vadmium commented on Mar 8, 2015

      @vadmium
      vadmium
      on Mar 8, 2015
      Member

      I’ve never actually used the Fraction class, but I doubt its behaviour should depend on whatever settings are in the current decimal context. Maybe you can extract the precision out of the format string, and base the internal decimal object on that.

    9. suutari commented on Mar 8, 2015

      @suutari
      suutarimannequin
      on Mar 8, 2015
      MannequinAuthor

      Eric V. Smith wrote:

      I'm not sure it needs fixing: it follows from the definition of using Decimal(num) / Decimal(denom). Plus, it's controllable with a decimal context:

      Hmm... Even though it's tempting to agree with you and just ignore the
      precision bug, but to be honest I have to agree with Martin Panter
      here. Depending on the current decimal context is not the way of
      "Least Surprise" when formatting Fractions.

      For all of the tests, I suggest using format(value, str) instead of ''.format(value). It more directly tests Fraction.__format__.

      I agree. Will change those.

      In general I think adding Fraction.__format__ is a good idea, and I think converting to Decimal is reasonable for the specified codes. My only question is what to do when "natively" formatting Fractions themselves. We might want to support field widths, padding, etc.

      Thanks! Actually I already tried to support field widths, padding and
      such. (See the test cases.) Or what do you mean?

    10. suutari commented on Mar 8, 2015

      @suutari
      suutarimannequin
      on Mar 8, 2015
      MannequinAuthor

      Here's the next round of the patch.

      For formatting fractions with any given precision I had to parse the precision from format specifier and at this point it seemed easier to just create a general parser for the Format Specification Mini-Language. In this patch it is implemented in fractions._parse_format_specifier function, but maybe this kind of general function should be moved to better place and be documented and exported. What do you think?

    11. vadmium commented on Mar 8, 2015

      @vadmium
      vadmium
      on Mar 8, 2015
      Member

      Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier()

    12. suutari commented on Mar 9, 2015

      @suutari
      suutarimannequin
      on Mar 9, 2015
      MannequinAuthor

      Martin Panter wrote:

      Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier()

      I did find that, but since it was a private function in private
      module, I was unsure if I can use it here. The _pydecimal one parser
      also does more stuff that I need.

    13. suutari commented on Mar 9, 2015

      @suutari
      suutarimannequin
      on Mar 9, 2015
      MannequinAuthor

      Version 3 of the patch. Changes to v2:

      • Use raw-strings for the regexps.
      • Make the specifier regexp more robust with \A, \Z and re.DOTALL.
      • Add more test cases; especially g and e formats and negative fractions.
    14. serhiy-storchaka
      self-assigned this
      on Mar 9, 2015

    15. serhiy-storchaka commented on Mar 21, 2015

      @serhiy-storchaka
      serhiy-storchaka
      on Mar 21, 2015
      Member
      >>> from fractions import Fraction as F
>>> format(F(4, 27), 'f')
'0.1481481'
>>> format(F(4, 27), '.1f')
'0.2'

    16. 15 remaining items

    17. vadmium commented on Mar 31, 2015

      @vadmium
      vadmium
      on Mar 31, 2015
      Member

      I understand double rounding to mean incorrectly rounding something like 0.149999 up to 0.2. It should be rounded once to 1 decimal place (0.1). If you temporarily round it to a higher number of places before rounding to 1 place, you’re doing it wrong. So you might have to ensure that any rounding done before formatting step exactly matches the rounding specified in the formatting.

    18. skrah commented on Mar 31, 2015

      @skrah
      skrahmannequin
      on Mar 31, 2015
      Mannequin

      It wouldn't be too bad if Py and C version of Decimal.__format__ had
      same interface. What do you think?

      Let's discuss that in a separate issue.

      [DefaultContext]

      I don't understand what do you mean with this. Is this something that
      I'm doing wrong in my patch or just another (related?) issue?

      Decimal.DefaultContext has global scope and currently affects
      Context() creation, unless you specify all parameters.

    19. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    20. mdickinson
      added a commit that references this issue on Jan 22, 2023

      gh-67790: Support float-style formatting for Fraction instances (#100161

      3e09f31

    21. mdickinson commented on Jan 22, 2023

      @mdickinson
      mdickinson
      on Jan 22, 2023
      Member

      Done for float-style formatting in #100161. I'm planning to make a new PR that adds support for the d presentation format before closing this issue.

    22. serhiy-storchaka
      assigned
      mdickinson
      and unassigned
      serhiy-storchaka
      on Oct 24, 2023
    23. mdickinson
      added a commit that references this issue on Oct 25, 2023

      pythongh-67790: Add integer-style formatting for Fraction type

      130c717

    24. mdickinson commented on Oct 25, 2023

      @mdickinson
      mdickinson
      on Oct 25, 2023
      Member

      I'm planning to make a new PR that adds support for the d presentation format before closing this issue.

      See #111320.

    25. mdickinson
      added a commit that references this issue on Dec 16, 2023

      gh-67790: Support basic formatting for Fraction (#111320)

      fe479fb
    26. aisk
      added a commit that references this issue on Feb 11, 2024

      pythongh-67790: Support basic formatting for Fraction (python#111320)

      d385fe6

    27. skirpichev commented on Feb 26, 2024

      @skirpichev
      skirpichev
      on Feb 26, 2024
      Member

      @mdickinson, #111320 was merged. From the issue thread it seems one could be closed.

    28. mdickinson commented on Mar 3, 2024

      @mdickinson
      mdickinson
      on Mar 3, 2024
      Member

      @skirpichev It could indeed! Thanks.

    29. mdickinson
      closed this as completedon Mar 3, 2024
    30. Glyphack
      added a commit that references this issue on Sep 2, 2024

      pythongh-67790: Support basic formatting for Fraction (python#111320)

      f8d56b9
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions