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.

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.

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

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.

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.

Committed in r83736.