Make float.__str__ behave identically to float.__repr__

[mdickinson]

BPO	9337
Nosy	@mdickinson, @ericvsmith
Files	issue9337.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/mdickinson'
closed_at = <Date 2010-08-04.20:57:08.850>
created_at = <Date 2010-07-23.10:30:57.855>
labels = ['interpreter-core', 'type-feature']
title = 'Make float.__str__ behave identically to float.__repr__'
updated_at = <Date 2010-08-04.20:57:08.849>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2010-08-04.20:57:08.849>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2010-08-04.20:57:08.850>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2010-07-23.10:30:57.855>
creator = 'mark.dickinson'
dependencies = []
files = ['18249']
hgrepos = []
issue_num = 9337
keywords = ['patch']
message_count = 6.0
messages = ['111268', '111582', '111930', '111934', '112088', '112891']
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/issue9337'
versions = ['Python 3.2']

[mdickinson]

Proposal: make the str of a float (or complex number) identical to the repr of a float (or complex number), in Python 3.2. This idea came up a couple of times at EuroPython, and generally met with approval.

An open question: what should be done on platforms that don't support the short float repr? In practice, I don't think this matters too much: it's difficult to find such platforms. The simplest thing to do would be to make __str__ identical to __repr__ on all platforms.

This change *will* inevitably break code; the question is whether this level of breakage is acceptable for 3.1 -> 3.2.

I'll also bring this up on the python-dev mailing list.

[ericvsmith]

I think this is a good idea. To test how much impact it would have, I changed float's str to return the same value as repr. regrtest broke only 3 tests: test_float test_tokenize test_unicodedata. It's not clear to me why unicodedata failed.

With short float repr, I don't think the str != repr distinction makes much sense.

[mdickinson]

Here's a patch. The floating-point part of the tutorial still needs work.

[mdickinson]

A couple of notes on the patch:

• the test_unicodedata failure was a result of computing a checksum involving str(numeric_value_of_character) for fraction characters like 1/6 and 2/3. I've changed the test to use '{.12g}'.format(numeric_value) instead, and updated the checksum.

• the patch changes the result of format(x, ''), so that it continues to match str(x) when x is a float or complex instance. So when there's no typecode and no precision given, float formatting behaves like repr/str; when there's no typecode but a precision *is* given, float formatting behaves like 'g' formatting, but always ensures at least one digit after the point for a result in non-scientific format (as before).

This change involves some slightly messy logic in formatter.h (which now needs to pass type 'r' to PyOS_double_to_string in this case); there may be a better way to write this code. Eric, if you have a chance to look at the formatter.h changes, I'd appreciate your comments.

[mdickinson]

Alexander Belopolsky pointed out another nice aspect of this change: after the change, let 'numerictype' be any of int, float, complex, Decimal or Fraction, and let 'x' be an instance of numerictype. Then

numerictype(str(x))

recovers x exactly.

See also additional discussion at:

http://mail.python.org/pipermail/python-dev/2010-July/102515.html

The consensus (so far) seems to be in favour of this change. I'll leave it a few more days in case people haven't seen the python-dev thread yet, and then assuming that there's no dissent I'll commit.

[mdickinson]

Committed in r83736.