Christopher Barker writes:
On Fri, Sep 11, 2020 at 12:09 AM Random832 <random832@fastmail.com> wrote:
What if we created a new syntax [and used it for the repr] that is not currently a valid identifier?
something like "1.INF"
Not for this please; save it for a case where we need it. I'm against any change by TOOWTDI and because inf and nan only exist in Python the language (including builtins) via casting strings to floats (there are no arithmetic operations that produce them). It seems right and proper to me that you import these from math (amusingly, math by itself doesn't seem to be enough to produce inf: the closest I've found is math.tan(math.pi/2.0) = 1.633123935319537e+16, and of course math.cot doesn't exist, while math.cos(0.0)/math.sin(0.0) just gives a ZeroDivisionError). But if there is going to be a change, just import inf and nan into the builtin namespace as identifiers. Steven d'Aprano made a pretty convincing case that you have to do something pretty perverse for this to cause trouble. Christopher Barker writes:
And I'd maybe go with .INF. :-)
Syntax using a leading dot has been proposed multiple times, most recently in the pattern matching thread (PEP 622 I think?). In the past it has been proposed as an abbreviation for the self.x = x pattern in __init__, and also in a Pascal-like with statement. I don't think we want to use it for something as small as fixing up one repr.
Another point is that these are not going to be singletons, like True, False and None
Singleton isn't the problem here. inf = None causes no problems if that's what you want to do. It's that those three names are keywords, and can't be used as identifiers. True and False caused problems because by introducing them the common idiom "False, True = 0, 1" became a syntax error.
-- they are just floats that happen to have particular values.
s/floats/identifiers/ The values are floats, but inf and nan are syntactically identifiers, not floats.