Implement __format__ for Fraction

[suutari]

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

• gh-67790: Support float-style formatting for Fraction instances #100161
• gh-67790: Support basic formatting for Fraction #111320

[suutari]

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

[suutari]

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

[serhiy-storchaka]

>>> from fractions import Fraction as F
>>> format(F(1, 3), '.30f')
'0.333333333333333333333333333300'

[suutari]

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.

[ericvsmith]

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.

[vadmium]

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.

[suutari]

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?

[suutari]

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?

[vadmium]

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

[suutari]

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.

[suutari]

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.

[serhiy-storchaka]

>>> from fractions import Fraction as F
>>> format(F(4, 27), 'f')
'0.1481481'
>>> format(F(4, 27), '.1f')
'0.2'