Issue 22951: unexpected return from float.repr() for inf, -inf, nan (original) (raw)

Issue22951

Created on 2014-11-26 19:47 by jaebae17, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (5)
msg231724 - (view)	Author: (jaebae17)	Date: 2014-11-26 19:47
The help page for the built-in repr() states ''' For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval()...''' This holds true for non-inf/nan values of float(): >>> eval(repr(float('0.0'))) 0.0 But for inf, -inf, and nan it does not: >>> eval(repr(float('inf'))) Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name 'inf' is not defined Expected return from repr(float('inf')) was "float('inf')", but perhaps 'inf' response has too much history at this point to be changed.
msg231755 - (view)	Author: Mark Dickinson (mark.dickinson) *	Date: 2014-11-27 12:01
Previously discussed here: http://bugs.python.org/issue1732212
msg231756 - (view)	Author: Mark Dickinson (mark.dickinson) *	Date: 2014-11-27 12:07
A couple of points against this change: 1. If repr(float('inf')) became "float('inf')", we'd lose the invariant that float(repr(x)) recovers x for all floats (including infinities and nans). 2. Since repr and str are currently identical for floats, this change would either end up modifying str too, or making str and repr different; neither option is particularly palatable. While I can see a case for the repr returning something eval-able, I think the str of an infinity should remain as "inf" or "-inf". 3. For consistency, you'd need to change the complex and Decimal outputs, too. 4. The current output of repr and str is directly parseable by most other languages. So -1 from me. (Changing type to 'enhancement'; we use 'behaviour' for bugs, and this isn't one. :-)
msg231757 - (view)	Author: Serhiy Storchaka (serhiy.storchaka) *	Date: 2014-11-27 12:19
Workaround: >>> eval('inf', {'inf': float('inf')}) inf
msg231846 - (view)	Author: Terry J. Reedy (terry.reedy) *	Date: 2014-11-29 01:17
Enhancements are only possible in 3.5 or beyond. I agree with Mark. There is no compelling reason to break code with this change. Hence it should be rejected. Float is an odd duck. All ints and all non-recursive lists, for instance, have a literal representation, and repr used that. No range objects, for instance, have a literal representation, so repr uses a evaluable 'range(start, stop[, step])' All float objects except 3 have a literal representation. Int and float are both unusual builtins in parsing a string input to produce a non-string object. For int, eval(repr(i)) == int(repr(i)) == i for all ints i. Similarly, eval(repr(f)) == float(repr(f)) == f for all float objects f *except* for the same 3 special objects. For those 3, a choice was make and we should stick with it.