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

No float formatting in PyString_FromFormat #47062

Closed
duaneb mannequin opened this issue May 10, 2008 · 17 comments
Closed

No float formatting in PyString_FromFormat #47062

duaneb mannequin opened this issue May 10, 2008 · 17 comments
Assignees
Labels
extension-modules C modules in the Modules dir interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@duaneb
Copy link
Mannequin

duaneb mannequin commented May 10, 2008

BPO 2813
Nosy @facundobatista, @mdickinson, @ericvsmith
Files
  • stringobject_format_f.patch: support for %f in PyString_FromFormat*
  • stringobject_format_Lf.patch: support for %f and %Lf in PyString_FromFormat*
  • stringobject_format_xLf.patch: support for %#zx, %f, %Lf in PyString_FromFormat*
  • 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/mdickinson'
    closed_at = <Date 2012-10-28.10:35:12.895>
    created_at = <Date 2008-05-10.21:09:06.260>
    labels = ['extension-modules', 'interpreter-core', 'type-feature']
    title = 'No float formatting in PyString_FromFormat'
    updated_at = <Date 2012-10-28.10:35:12.894>
    user = 'https://bugs.python.org/duaneb'

    bugs.python.org fields:

    activity = <Date 2012-10-28.10:35:12.894>
    actor = 'mark.dickinson'
    assignee = 'mark.dickinson'
    closed = True
    closed_date = <Date 2012-10-28.10:35:12.895>
    closer = 'mark.dickinson'
    components = ['Extension Modules', 'Interpreter Core']
    creation = <Date 2008-05-10.21:09:06.260>
    creator = 'duaneb'
    dependencies = []
    files = ['10697', '10706', '10720']
    hgrepos = []
    issue_num = 2813
    keywords = ['patch']
    message_count = 17.0
    messages = ['66586', '68509', '68523', '68552', '68596', '68597', '68609', '68610', '68691', '87617', '87671', '110633', '110634', '110668', '110673', '110715', '174027']
    nosy_count = 7.0
    nosy_names = ['facundobatista', 'mark.dickinson', 'eric.smith', 'MrJean1', 'duaneb', 'riq', 'BreamoreBoy']
    pr_nums = []
    priority = 'normal'
    resolution = 'out of date'
    stage = 'patch review'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue2813'
    versions = ['Python 3.3']

    @duaneb
    Copy link
    Mannequin Author

    duaneb mannequin commented May 10, 2008

    There appears to be most of the formatting options in the *printf
    family... except for the obvious %f. Why is this crucial option missing?

    @duaneb duaneb mannequin added extension-modules C modules in the Modules dir interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels May 10, 2008
    @riq
    Copy link
    Mannequin

    riq mannequin commented Jun 21, 2008

    Do you expect to have support for float, double and long double ?
    Also, do you expect to have support for precision-modifiers ?

    @duaneb
    Copy link
    Mannequin Author

    duaneb mannequin commented Jun 21, 2008

    Well, precision modifiers would be nice, but I don't think that they're
    necessarily needed. General floating point support, however, is needed.

    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jun 21, 2008

    Attached is a patch attempting to provide support for %f with precision in PyString_FromFormat* based on file Objects/stringobject.c of Python 2.6b1.

    Note, only %f is support but %lf is not and silently ignored.

    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jun 22, 2008

    Attached is another patch for file Objects/stringobject.c(relative to
    Python 2.6b1) which supports the double %f and long double %LF formats.

    However, %Lf is included only if symbol LDBL_DIG is defined in header
    file <float.h> on the underlying platform.

    This patch also handles the long and size_t flags correctly in the first
    loop to determine the size of the buffer under
    ...
    case 'd': case 'u': case 'i': case 'x':
    ...

    Btw, it does not make sense to handle float since there is not formnat
    specification for floats.

    @facundobatista
    Copy link
    Member

    Jean, you can increase *hugely* the possibility of this being accepted
    if you submit a comprehensive suite test for this.

    Thanks!!

    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jun 23, 2008

    Another rev of the patch now including updates to 2 documentation files:
    Doc/c-api/exceptions.rst and Doc/c-api/string.rst. As before the patch is
    relative to the source of Python 2.6b1.

    Where should test cases for the new formats in the PyString_FromFormat*
    and PyErr_Format functions be added?

    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jun 23, 2008

    The tests for PyString_FromFormat are in file Modules/_testcapimodule.c.

    Attached is yet another update of the patch, this one also includes 3
    tests for the new %f format specification added to file
    Modules/_testcapimodule.c.

    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jun 24, 2008

    Here is another patch for PyString_FromFormat* adding support for 'l' and
    'z' type specifications for the '%x' format and an optional '#' to prepend
    '0x' to the hex result. In addition, the '%p' format is handled as '%#x'.

    Updates for the c-api tests and the documentation for exceptions and
    string are also included in the patch.

    Like before, the patch is a forward delta to the files of Python 2.6b1.

    @ericvsmith
    Copy link
    Member

    From the code:

    /* assume %f produces at most (L)DBL_DIG
    digits before and after the decimal
    point, plus the latter plus a sign */

    This is not correct. DBL_DIG is 15 on my x86 Linux machine.
    printf("%.*f\n", DBL_DIG, 1e20) produces a string that's 37 characters
    long. It might be best to use PyOS_double_to_string instead of snprintf,
    although we don't support long double there. I'm not sure long double
    support is all that important in practice (for Python), though.

    It would be easier to review this if the %p change weren't also
    included. That's looks like a good change, but it's a separate issue.

    unicodeobject.c should also be modified. In 3.x, it's unicodeobject.c
    and bytesobject.c that need to work.

    @mdickinson
    Copy link
    Member

    I also think it would be good to use PyOS_double_to_string here. That
    does make it impossible to format long doubles, though, except by doing
    a possibly lossy conversion to double first.

    As far as I can see, Python doesn't use long double anywhere outside the
    ctypes module, so I'm not sure that long double support really matters
    right now.

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jul 18, 2010

    Jean, do you intend taking this issue any further or can it be closed?

    @mdickinson
    Copy link
    Member

    I'll take a look at this.

    @mdickinson mdickinson self-assigned this Jul 18, 2010
    @MrJean1
    Copy link
    Mannequin

    MrJean1 mannequin commented Jul 18, 2010

    Mark L,

    No, I do not intend to take this issue further. Rather the opposite, it should probably be paired down based on the recent comments. Specifically, use PyOS_double_to_string, remove support for long double and perhaps more.

    Also, the patches I created are more than 2 years old and will need to be updated against the current stringobject.c code. There are quite a few changes in the 2.7 version of that file since early 2.6.

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jul 18, 2010

    Closing as Jean has no interest in keeping it open.

    @BreamoreBoy BreamoreBoy mannequin closed this as completed Jul 18, 2010
    @mdickinson
    Copy link
    Member

    Jean may have no interest in moving this forward, but I do. (Which is why I assigned the issue to me.)

    @mdickinson mdickinson reopened this Jul 19, 2010
    @mdickinson
    Copy link
    Member

    Okay, I've failed to take this forward. Reclosing as out of date.

    @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
    extension-modules C modules in the Modules dir interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants