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

Float formatting with no type code produces incorrect output for exponential notation #49936

Closed
ericvsmith opened this issue Apr 4, 2009 · 4 comments
Assignees
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@ericvsmith
Copy link
Member

BPO 5686
Nosy @mdickinson, @ericvsmith

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-04-05.13:26:36.874>
created_at = <Date 2009-04-04.12:20:16.175>
labels = ['interpreter-core', 'type-bug', 'invalid']
title = 'Float formatting with no type code produces incorrect output for exponential notation'
updated_at = <Date 2009-04-05.13:26:36.873>
user = 'https://github.com/ericvsmith'

bugs.python.org fields:

activity = <Date 2009-04-05.13:26:36.873>
actor = 'eric.smith'
assignee = 'eric.smith'
closed = True
closed_date = <Date 2009-04-05.13:26:36.874>
closer = 'eric.smith'
components = ['Interpreter Core']
creation = <Date 2009-04-04.12:20:16.175>
creator = 'eric.smith'
dependencies = []
files = []
hgrepos = []
issue_num = 5686
keywords = []
message_count = 4.0
messages = ['85386', '85387', '85391', '85489']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'eric.smith']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5686'
versions = ['Python 2.6', 'Python 3.0', 'Python 3.1', 'Python 2.7']

@ericvsmith
Copy link
Member Author

If no format specifier is supplied to a float, it's supposed to work
like 'g', but with at least one digit after the decimal. This works for
non-exponential notation:

>>> format(1., '')
'1.0'
>>> format(1., 'g')
'1'

But for exponential notation, it does not:
>>> format(1e200, '')
'1e+200'
>>> 
>>> format(1e200, 'g')
'1e+200'

@ericvsmith ericvsmith self-assigned this Apr 4, 2009
@ericvsmith ericvsmith added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels Apr 4, 2009
@ericvsmith
Copy link
Member Author

The documentation doesn't agree with the PEP. The docs at
http://docs.python.org/library/string.html#formatstrings just say '' is
the same as 'g'. It does not draw a distinction between exponential and
fixed output.

The PEP has the "at least one digit after the decimal" language. It also
does not draw a distinction between exponential and fixed output.

@mdickinson
Copy link
Member

I don't really see this as a bug in the behaviour. I'd always understood
the purpose of the "at least one digit after the decimal" to be to make it
possible to visually distinguish floats and integers, in the same way that
repr and str already do.

>>> repr(1e100)
'1e+100'
>>> repr(1e5)
'100000.0'

If an exponent's present then the string's already clearly not an integer,
so there's no need for the '.0'.

@ericvsmith
Copy link
Member Author

This isn't testing what I thought it was testing. I'd forgotten that
format(x, '') is exactly equivalent to str(x).

The better test is using a format string of '<':
>>> 1e200.__format__('<')
'1.0e+200'
>>> 1e200.__format__('<g')
'1e+200'

So this is a non-issue: the current behavior matches the PEP
description. The online docs could still be tweaked, though.

@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) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants