If, in the future, Python used a library such as MPFR and made all floats a given precision (say, by giving a flag to the interpreter "python -prec2048"), it would never be enough to make infinity because it only has the limitation of a 64 bit exponent.

This is just an example of course, probably won't happen, but when I read "1e1000" or such a number it doesn't strike me as infinite (although a particular version of IEEE floating point may consider it that), it strikes me as a lazy programmer who thinks it's bigger than any other number he's processing. I've added this case to my PEP .rst file and why it's not a good solution


On Sat, Sep 12, 2020, 8:25 AM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Guido van Rossum writes:

 > I don't actually understand why Stephen made this claim about
 > arithmetic operations,

Stephen is often mistaken about computers (among many topics).  That's
why he mostly posts on -ideas, and mostly throws drafts away rather
than post them. :-)

I would not claim that evaluating a literal such as 1e1000 is not an
arithmetic operation, I just "forgot" that these examples exist
(mostly in a context of trying to get NaN with math.asin(2) and got
ValueError instead ;-/ ).

I still stand by the argument that since some common ways of producing
true infinities (rather than overflows) and NaNs such as 1.0/0.0 and
0.0/0.0 end up as Exceptions rather than float values, inf and nan
have rather small usefulness in Python with only builtins, especially
nan.  "from math import inf" has to be the least annoying thing about
working with infinities and overflows in Python (which, to be fair, is
quite annoying in any context, on computers or on paper).
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/22TKQDJV4PNMOK5KUAX74QHX3KP74XCT/
Code of Conduct: http://python.org/psf/codeofconduct/