The repr() for a float of 'inf' or 'nan' is generated as a string (not a string literal). Perhaps this is only important in how one defines repr(). I've filed a bug, but am not sure if there is a clear solution.
<br><br><a href="https://sourceforge.net/tracker/?func=detail&amp;atid=105470&amp;aid=1732212&amp;group_id=5470">https://sourceforge.net/tracker/?func=detail&amp;atid=105470&amp;aid=1732212&amp;group_id=5470</a><br><br># Repr with a tuple of floats
<br>
&gt;&gt;&gt; repr((1.0, 2.0, 3.0))<br>
&#39;(1.0, 2.0, 3.0)&#39;<br>
&gt;&gt;&gt; eval(_)<br>
(1.0, 2.0, 3.0)<br>
<br># Repr with a tuple of floats, plus nan<br>
&gt;&gt;&gt; repr((1.0, float(&#39;nan&#39;), 3.0))<br>
&#39;(1.0, nan, 3.0)&#39;<br>
&gt;&gt;&gt; eval(_)<br>
NameError: name &#39;nan&#39; is not defined<br><br>There are a few alternatives I can think are fairly clean. I think I&#39;d prefer any of these over the current &#39;nan&#39; implementation. I don&#39;t think it is worth adding a nan literal into the language. But something could be changed so that repr of nan meant something.
<br><br>Best option in my opinion would be adding attributes to float, so that float.nan, float.inf, and float.ninf are accessable. This could also help with the odd situations of checking for these out of range values. With that in place, repr could return &#39;
float.nan&#39; instead of &#39;nan&#39;. This would make the repr string evaluatable again. (In contexts where __builtins__ has not been molested)<br><br>Another option could be for repr to return &#39;float(&quot;nan&quot;)&#39; for these, which would also evaluate correctly. But this doesn&#39;t seem a clean use for repr.
<br><br>Is this worth even changing? It&#39;s just an irregularity that has come up and surprised a few of us developers.<br><br>