GeezerVison is showing github.com — Implement __format__ for Fraction · Issue #67790 · python/cpython
Implement __format__ for Fraction #67790Description
| 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 documentationissue23602v2.patchissue23602v3.patchissue23602v4.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
Activitysuutari commented on Mar 7, 2015 MannequinAuthor More actions Since Decimal supports __format__, it would be nice that Fraction did too. suutari commented on Mar 7, 2015 MannequinAuthor More actions Here's a patch that adds Fraction.__format__ implementation, test cases and documentation. serhiy-storchaka commented on Mar 7, 2015 >>> from fractions import Fraction as F
>>> format(F(1, 3), '.30f')
'0.333333333333333333333333333300' suutari commented on Mar 8, 2015 MannequinAuthor More actions 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 commented on 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:
>>> 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 commented on 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 commented on Mar 8, 2015 MannequinAuthor More actions 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 commented on Mar 8, 2015 MannequinAuthor More actions 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 commented on Mar 8, 2015 Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier() suutari commented on Mar 9, 2015 MannequinAuthor More actions 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 commented on Mar 9, 2015 MannequinAuthor More actions 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 commented on Mar 21, 2015 >>> from fractions import Fraction as F
>>> format(F(4, 27), 'f')
'0.1481481'
>>> format(F(4, 27), '.1f')
'0.2' vadmium commented on 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 commented on Mar 31, 2015
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. mdickinson commented on Jan 22, 2023 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. mdickinson commented on Oct 25, 2023
I'm planning to make a new PR that adds support for the d presentation format before closing this issue.
See #111320. skirpichev commented on Feb 26, 2024 mdickinson commented on Mar 3, 2024
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|