[Python-ideas] math.inf and math.nan constants

[Stephen J. Turnbull]

Chris Barker writes:

 > Making math.nan a singleton is a bad idea for many reasons already
 > mentioned.

But it's not a singleton, not even in the class of NaNs.  It's a named
constant, like zero or pi.

True, the name is ambiguous in the sense that it's easy to forget that
(unlike zero and pi) this NaN-with-a-name is not otherwise special in
any NaN-y way you can depend on, and that's slightly dangerous.  I
dislike it -- AFAICS math.nan is pretty useless: if you need a
particular NaN repeatedly, I still don't see why "nan = float('nan')"
is unsatisfactory, and I worry that multiple package writers might use
it as "the NaN to return for undefined operations", competing for the
role of "my NaN" (cf the idea suggested that NaN payload could be used
to track the module that produced it).  That's different from
math.inf, which seems like a reasonable addition with no real downside
(although similarly little upside AFAICS).

But I have to give the advocates this point: I think it's much less
likely that people will write "x is math.nan" with poor results than
that they will write "x == math.pi",and it's the same group that would
likely fall prey to both.

 > Though it would be pretty cool if you could override "is" to make:
 > 
 > x is math.nan
 > 
 > be:
 > 
 > math.isnan(x)

In Python we spell that "isinstance", not "is".