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

[Bruce Leban]

On Wed, Jan 7, 2015 at 8:09 AM, Steven D'Aprano <steve at pearwood.info> wrote:

> In any case, we're talking about an utterly trivial micro-optimization.
> This is Python, not Unix shell scripting. We don't use names like
> "umount" to save one character over "unmount", we encouraging writing
> for clarity and correctness over brevity.
>
> The math module has constants pi and e because it would be truly an
>
inconvenience to have to create them yourself:
>
>   pi = 3.14159265389793
>
> You're missing one key detail. If I see math.nan or math.inf in code, I
know what those values are. If I see a bare nan or inf in the code I don't.
That's an inconvenience too.


> Up to now, I have only discussed inf, not nan, because there is only one
> inf value in floats. (Two if you count -inf.) But the IEEE 754 standard
> provides many different NAN values, and offers a possible interpretion
> of them: the extra "payload" on each NAN can be used to carry diagnostic
> information on which numeric operation failed.
>

This is a red herring as any future change to support this won't
automatically touch code that uses float("nan") just as it won't touch code
that uses float.nan.

There is a problem here but that's not it. The problem is that

float("nan") is float("nan") => False
math.nan is math.nan => True


So is this an attractive nuisance that will make people think they can
should use x is math.nan instead of math.isnan(x)? Hopefully not but
something to consider. Pylint should flag this usage.

--- Bruce
Check out my new puzzle book: http://Ju.mp/ingToConclusions
Get it free here: http://Ju.mp/ingToConclusionsFree (available on iOS)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150107/3bc94f1d/attachment.html>