Repository navigation
Implement __format__ for Fraction #67790
Description
| BPO | 23602 |
|---|---|
| Nosy | @rhettinger, @mdickinson, @scoder, @ericvsmith, @ezio-melotti, @skrah, @vadmium, @serhiy-storchaka, @wm75, @skirpichev, @suutari |
| Files |
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']
Activity
suutari commentedon Mar 7, 2015
Since Decimal supports __format__, it would be nice that Fraction did too.
suutari commentedon Mar 7, 2015
Here's a patch that adds Fraction.__format__ implementation, test cases and documentation.
serhiy-storchaka commentedon Mar 7, 2015
suutari commentedon Mar 8, 2015
Good catch! I'll try to fix this and add some more test cases.
ericvsmith commentedon Mar 8, 2015
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:
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 commentedon Mar 8, 2015
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 commentedon Mar 8, 2015
Eric V. Smith wrote:
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.
I agree. Will change those.
Thanks! Actually I already tried to support field widths, padding and
such. (See the test cases.) Or what do you mean?
suutari commentedon Mar 8, 2015
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 commentedon Mar 8, 2015
Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier()
suutari commentedon Mar 9, 2015
Martin Panter wrote:
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 commentedon Mar 9, 2015
Version 3 of the patch. Changes to v2:
serhiy-storchaka commentedon Mar 21, 2015
15 remaining items
vadmium commentedon Mar 31, 2015
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.
skrah commentedon Mar 31, 2015
Let's discuss that in a separate issue.
[DefaultContext]
Decimal.DefaultContext has global scope and currently affects
Context() creation, unless you specify all parameters.
gh-67790: Support float-style formatting for Fraction instances (#100161
mdickinson commentedon Jan 22, 2023
Done for float-style formatting in #100161. I'm planning to make a new PR that adds support for the
dpresentation format before closing this issue.pythongh-67790: Add integer-style formatting for Fraction type
mdickinson commentedon Oct 25, 2023
See #111320.
gh-67790: Support basic formatting for Fraction (#111320)
pythongh-67790: Support basic formatting for Fraction (python#111320)
skirpichev commentedon Feb 26, 2024
@mdickinson, #111320 was merged. From the issue thread it seems one could be closed.
mdickinson commentedon Mar 3, 2024
@skirpichev It could indeed! Thanks.
pythongh-67790: Support basic formatting for Fraction (python#111320)