Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alternate float formatting styles to new-style formatting. #51343

Closed
mdickinson opened this issue Oct 9, 2009 · 21 comments
Closed

Add alternate float formatting styles to new-style formatting. #51343

mdickinson opened this issue Oct 9, 2009 · 21 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir type-feature A feature request or enhancement

Comments

@mdickinson
Copy link
Member

BPO 7094
Nosy @rhettinger, @terryjreedy, @mdickinson, @ericvsmith, @ezio-melotti, @merwok, @skrah
Files
  • issue7094.diff
  • 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/ericvsmith'
    closed_at = <Date 2014-05-24.23:31:18.380>
    created_at = <Date 2009-10-09.19:54:03.106>
    labels = ['interpreter-core', 'type-feature', 'library']
    title = 'Add alternate float formatting styles to new-style formatting.'
    updated_at = <Date 2015-05-30.00:21:04.068>
    user = 'https://github.com/mdickinson'

    bugs.python.org fields:

    activity = <Date 2015-05-30.00:21:04.068>
    actor = 'terry.reedy'
    assignee = 'eric.smith'
    closed = True
    closed_date = <Date 2014-05-24.23:31:18.380>
    closer = 'eric.smith'
    components = ['Interpreter Core', 'Library (Lib)']
    creation = <Date 2009-10-09.19:54:03.106>
    creator = 'mark.dickinson'
    dependencies = []
    files = ['19753']
    hgrepos = []
    issue_num = 7094
    keywords = ['patch']
    message_count = 21.0
    messages = ['93807', '93808', '93809', '95913', '113442', '113623', '121760', '121828', '121963', '121969', '121970', '121971', '121992', '122012', '122375', '185760', '218962', '219016', '219065', '244428', '244432']
    nosy_count = 8.0
    nosy_names = ['rhettinger', 'terry.reedy', 'mark.dickinson', 'eric.smith', 'ezio.melotti', 'eric.araujo', 'skrah', 'Seungbeom Kim']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue7094'
    versions = ['Python 3.5']

    @mdickinson
    Copy link
    Member Author

    Python's old-style formatting supports the use of an alternative form
    (specified by including a '#' in the format) for 'e', 'f' and 'g'
    formatting:

    Python 3.2a0 (py3k:75275:75276, Oct  7 2009, 20:26:36) 
    [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> '%.17g' % 1.2
    '1.2'
    >>> '%#.17g' % 1.2
    '1.2000000000000000'

    New-style formatting doesn't currently support this:

    >>> format(1.2, '#.17g')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Alternate form (#) not allowed in float format specifier

    To aid migration from old-style to new-style formatting, it might be worth
    adding the alternate forms. At least the float, complex and Decimal types
    would be affected.

    @mdickinson mdickinson added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Oct 9, 2009
    @ericvsmith
    Copy link
    Member

    I'm adding 2.7. Since 2.7 and 3.2 share the same code base, I'd rather
    add it to both if we're going to do it at all.

    @ericvsmith ericvsmith self-assigned this Oct 9, 2009
    @mdickinson
    Copy link
    Member Author

    Just for reference, the effect of the alternative style is explained
    succinctly in the C99 standard (well, the N1256 draft, anyway):

    "For a, A, e, E, f, F, g, and G conversions, the result of converting a
    floating-point number always contains a decimal-point character, even if
    no digits follow it. (Normally, a decimal-point character appears in the
    result of these conversions only if a digit follows it.) For g and G
    conversions, trailing zeros are not removed from the result. For other
    conversions, the behavior is undefined."

    @ericvsmith
    Copy link
    Member

    When and if this is implemented, there's a test in test_float.py that
    needs to be deleted. Search on "if not '#' in fmt:", added in r76632.

    @terryjreedy
    Copy link
    Member

    I believe this is covered by the PEP-3003 3.2 change moratorium.

    @rhettinger
    Copy link
    Contributor

    I do not believe that this is covered by the moratorium. It's important for 3.x success to get new string formatting to its highest state of usability. Matching published standards and practices(i.e. C99) and improving ability to convert from old-style to new style are both very helpful in this regard.

    @ericvsmith
    Copy link
    Member

    Also note that if # is added for float and Decimal, it should be added for complex. My Bug Day sprint group will have a patch for this shortly.

    @ericvsmith
    Copy link
    Member

    This is the patch developed today at the DCPython sprint. I have not reviewed it very well. I know that at least:

    • formatting is not consistent
    • the docs need reviewing
    • I want to add more tests
    • Misc/NEWS and Misc/ACKS need updating

    But I'm uploading it here anyway so that it doesn't get lost. I'll be refining the patch over the next several days. The patch covers float, complex, and decimal.

    Thanks to:
    Eric Groo
    Vlad Korolev
    Bob Schmertz
    Owen Martin

    @ericvsmith
    Copy link
    Member

    Updated patch. I'm pretty happy with this one and will commit it after review.

    @mdickinson
    Copy link
    Member Author

    I haven't done a full review, but this looks good at first glance.

    For '#g' formatting on the Decimal type, I wonder whether the patch gives the right semantics. E.g., should

    format(Decimal('1.23'), '#.6g')

    give '1.23' or '1.23000'? For the float type, the '#.<precision>g' formatting has the property that <precision> digits are always returned, and I think this may be what we want here. I'm not sure, though.

    @mdickinson
    Copy link
    Member Author

    I think the change below is sufficient if we decide that the '#g' formatting should always have the given number of significant digits.

    --- Lib/decimal.py      (revision 86635)
    +++ Lib/decimal.py      (working copy)
    @@ -3701,7 +3701,8 @@
                     self = self._round(precision+1, rounding)
                 elif spec['type'] in 'fF%':
                     self = self._rescale(-precision, rounding)
    -            elif spec['type'] in 'gG' and len(self._int) > precision:
    +            elif spec['type'] in 'gG' and (len(self._int) > precision or
    +                                           spec['alt']):
                     self = self._round(precision, rounding)
             # special case: zeros with a positive exponent can't be
             # represented in fixed point; rescale them to 0e0.

    @mdickinson
    Copy link
    Member Author

    Gah. That doesn't work for zeros, though.

    Apart from this, the rest of the patch looks good, and all tests pass on my machine. (Well, except for test_urllib2_localnet, but I'm pretty sure that failure is unrelated.)

    I hadn't realized the use_alt_formatting stuff was already present in Python/pystrtod.c.

    @ericvsmith
    Copy link
    Member

    I didn't realize it either, or I would have done this patch months ago. But of course it's needed for %-formatting.

    I'll consider the 'g' case and see what I come up with.

    @ericvsmith
    Copy link
    Member

    I agree that:
    format(Decimal('1.23'), '#.6g')
    should give '1.23000', just as:
    format(1.23, '#.6g')
    does.

    I'll work on fixing the patch, although if I don't get to it in the next few days I'll commit the existing patch and open another issue, just to make sure this gets in before the beta.

    @ericvsmith
    Copy link
    Member

    Checked in r86751. I'm leaving this open until I fix the remaining issue with '#g' for Decimal.

    @ericvsmith ericvsmith added the stdlib Python modules in the Lib dir label Nov 25, 2010
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Apr 1, 2013

    @eric looks as if the bulk of the work has been done so would you like to dot the i's and cross the t's?

    @skrah
    Copy link
    Mannequin

    skrah mannequin commented May 23, 2014

    This might be out of date: _decimal has never implemented alternate
    formatting and so far there have been no reported issues.

    Another data point: Go apparently implements alternate formatting
    only for octal, hex and strings:

    http://golang.org/pkg/fmt/

    So I'm unsure if anyone is actually using alternate formatting.
    I think complaints about 2-to-3 porting problems should have
    surfaced by now.

    @rhettinger
    Copy link
    Contributor

    So I'm unsure if anyone is actually using alternate formatting.

    That makes sense. Any further effort should wait until there is known demand. Otherwise, we risk growing the API with codes that aren't used.

    @ericvsmith
    Copy link
    Member

    I'm going to go ahead and close this. Alternate formatting was added to float and complex. I think leaving this issue open just confuses whether or not that support was added. I know I had to go back and double check.

    Since decimal never participated in %-formatting, there are no "migration to .format()" issues with it. I agree that it's unlikely anyone would want it, and if we want to add it, it would be a new, separate issue.

    @SeungbeomKim
    Copy link
    Mannequin

    SeungbeomKim mannequin commented May 29, 2015

    It looks like this change has not been applied to Python 2.7. Do we have any chance of getting it to 2.7?

    So I'm unsure if anyone is actually using alternate formatting.

    The "alternative form" is my favorite, and I think that "%#g" should be the default format for general floating-point values in numerical applications. That is why I miss this feature in Python 2.7 so much.

    @terryjreedy
    Copy link
    Member

    New features only go in new versions.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core (Objects, Python, Grammar, and Parser dirs) stdlib Python modules in the Lib dir type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    4 participants