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 < firstname.lastname@example.org> 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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://email@example.com/message/22TKQD... Code of Conduct: http://python.org/psf/codeofconduct/