classification
Title: Make float.__str__ behave identically to float.__repr__
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: eric.smith, mark.dickinson
Priority: normal Keywords: patch

Created on 2010-07-23 10:30 by mark.dickinson, last changed 2010-08-04 20:57 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
issue9337.patch mark.dickinson, 2010-07-29 14:09
Messages (6)
msg111268 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-23 10:30
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.
msg111582 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-07-25 23:53
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.
msg111930 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-29 14:09
Here's a patch.  The floating-point part of the tutorial still needs work.
msg111934 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-29 14:19
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.
msg112088 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-30 17:27
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.
msg112891 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-04 20:57
Committed in r83736.
History
Date User Action Args
2010-08-04 20:57:08mark.dickinsonsetstatus: open -> closed
resolution: accepted
messages: + msg112891

stage: commit review -> resolved
2010-07-30 17:27:38mark.dickinsonsetmessages: + msg112088
stage: needs patch -> commit review
2010-07-29 14:19:06mark.dickinsonsetmessages: + msg111934
2010-07-29 14:09:21mark.dickinsonsetfiles: + issue9337.patch
keywords: + patch
messages: + msg111930
2010-07-25 23:53:18eric.smithsetmessages: + msg111582
2010-07-23 10:30:57mark.dickinsoncreate