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

Make '%F' and float.__format__('F') convert results to upper case. #47632

Closed
ericvsmith opened this issue Jul 16, 2008 · 12 comments
Closed

Make '%F' and float.__format__('F') convert results to upper case. #47632

ericvsmith opened this issue Jul 16, 2008 · 12 comments
Assignees
Labels
easy interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@ericvsmith
Copy link
Member

BPO 3382
Nosy @mdickinson, @ericvsmith
Files
  • issue3382_trunk.patch
  • issue3382_trunk-1.patch
  • 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 2009-11-29.17:41:25.337>
    created_at = <Date 2008-07-16.18:28:14.175>
    labels = ['interpreter-core', 'easy', 'type-feature']
    title = "Make '%F' and float.__format__('F') convert results to upper case."
    updated_at = <Date 2009-11-29.17:41:25.335>
    user = 'https://github.com/ericvsmith'

    bugs.python.org fields:

    activity = <Date 2009-11-29.17:41:25.335>
    actor = 'eric.smith'
    assignee = 'eric.smith'
    closed = True
    closed_date = <Date 2009-11-29.17:41:25.337>
    closer = 'eric.smith'
    components = ['Interpreter Core']
    creation = <Date 2008-07-16.18:28:14.175>
    creator = 'eric.smith'
    dependencies = []
    files = ['15412', '15414']
    hgrepos = []
    issue_num = 3382
    keywords = ['patch', 'easy']
    message_count = 12.0
    messages = ['69811', '69897', '69901', '71945', '86838', '87092', '87330', '95802', '95805', '95807', '95808', '95810']
    nosy_count = 2.0
    nosy_names = ['mark.dickinson', 'eric.smith']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue3382'
    versions = ['Python 3.1', 'Python 2.7']

    @ericvsmith
    Copy link
    Member Author

    See http://mail.python.org/pipermail/python-dev/2008-July/081242.html
    for the discussion. Basically, 'F' did the same as 'f' because it was
    assumed that neither would ever produce an exponent. But they do, for
    numbers greater than about 1e50. Also, 'F' should produce 'NAN' for
    cases where 'f' produces 'nan'.

    @ericvsmith ericvsmith self-assigned this Jul 16, 2008
    @ericvsmith ericvsmith added interpreter-core (Objects, Python, Grammar, and Parser dirs) easy type-feature A feature request or enhancement labels Jul 16, 2008
    @ericvsmith
    Copy link
    Member Author

    Implemented for trunk in r65069; for py3k in r65073.

    @ericvsmith
    Copy link
    Member Author

    Changes backed out, pending fixing on Windows.

    @ericvsmith ericvsmith reopened this Jul 17, 2008
    @ericvsmith
    Copy link
    Member Author

    Unfortunately, I missed the window to get these into 3.0 and 2.6.
    Better luck for 3.1 and 2.7!

    @ericvsmith
    Copy link
    Member Author

    If http://bugs.python.org/issue5859 is implemented, then this issue
    really just becomes making sure NAN and INF are uppercase.

    @ericvsmith
    Copy link
    Member Author

    With the implementation of bpo-5859 (py3k only), the only case where
    this matters in NAN and INF. I'm going to address those in 3.1, and not
    make any change for 2.x.

    @ericvsmith
    Copy link
    Member Author

    Checked in to py3k in 72398. I'm reconsidering whether to make this
    change in 2.7. I might make the change there, I'll have to check on the
    impacts.

    @mdickinson
    Copy link
    Member

    Eric, any further thoughts about making this change in 2.7? Here's a
    patch that does it (I think).

    @ericvsmith
    Copy link
    Member Author

    Thanks for looking at this, Mark.

    Your patch looks okay to me, but Objects/stringlib/formatter.h still has
    some 'F' -> 'f' logic in it, although it turns out that it's wrong:

    #if PY_VERSION_HEX < 0x0301000
        /* 'F' is the same as 'f', per the PEP */
        /* This is no longer the case in 3.x */
        if (type == 'F')
            type = 'f';
    #endif

    Note that it's missing a zero on the end, so this code is never (and I
    guess never was) executed. I'll remove it and add a test.

    It also looks like complex is still mapping 'F' to 'f'. I'll fix that,
    too, and add a test for it.

    Thanks again.

    @ericvsmith
    Copy link
    Member Author

    Here's a patch which adds some tests and fixes complex.

    I'm currently testing with PY_NO_SHORT_FLOAT_REPR on Windows. If that's
    okay, and if you don't have any objections, I'll commit this. While I'm
    at it I'll modify Objects/stringlib/formatter.h in py3k to keep them it
    sync with trunk.

    @mdickinson
    Copy link
    Member

    Looks good to me.

    @ericvsmith
    Copy link
    Member Author

    Committed (with a few more tests) in r76583.

    @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
    easy interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants