Issue 1732212: repr of 'nan' floats not parseable (original) (raw)

Issue1732212

Created on 2007-06-06 16:50 by shredwheat, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg32231 - (view)	Author: Pete Shinners (shredwheat)	Date: 2007-06-06 16:50
The repr of float('nan') is not parsable as a literal in Python. If the repr of 'nan' became "float('nan')" then the result could be evaluated to produce the same results. A better possible solution would be to add "nan" and "inf" as attributes on float. These would be accessed as "float.nan" and "float.inf". This doesn't allow for "-inf" as cleanly, but "float.ninf" could be acceptable. Repr would be changed to return these. A patch can be provided if the solution sounds resonable. >>> repr((1.0, 2.0, 3.0)) '(1.0, 2.0, 3.0)' >>> eval(_) (1.0, 2.0, 3.0) >>> repr((1.0, float('nan'), 3.0)) '(1.0, nan, 3.0)' >>> eval(_) NameError: name 'nan' is not defined
msg32232 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2007-06-06 18:40
Please discuss this on python-dev.
msg81572 - (view)	Author: Daniel Diniz (ajaksu2) *	Date: 2009-02-10 18:12
OP posted a message in python-dev, with no replies: http://mail.python.org/pipermail/python-dev/2007-June/073625.html
msg81589 - (view)	Author: Mark Dickinson (mark.dickinson) *	Date: 2009-02-10 19:46
I don't see a huge need for this. In 2.6, 3.0 and higher, float(repr(x)) recovers x reliably across platforms (modulo the occasional system strtod bug), even when x is an infinity or nan. It's true that using float() doesn't help if you want to eval the repr of a container with nans in it. But in that situation it's not hard to prefix the eval with "nan = float('nan'); inf = float('inf')". Pete, are you still interested in this? Can you suggest a solution that doesn't mess up the float(repr(.)) round- trip? I don't really want to lose the float(repr(.)) round-trip.
msg81604 - (view)	Author: Raymond Hettinger (rhettinger) *	Date: 2009-02-10 21:33
Recommend closing this. We like to have eval(repr(obj))==obj where possible but it is not a strict requirement. Am opposed to the two proposed solutions (float attributes or new literals). Mark's solution of defining nan=float('nan') whereever you care about it seems like a reasonable workaround. IMO, the special case code we've already added to support NaNs and Infs has already far exceeded their worth in real-world use cases. No need to further muddy the waters when simple workarounds exist.