On Sat, Sep 5, 2020 at 10:00 AM Steven D'Aprano steve@pearwood.info wrote:
By the way, the numpy inf is a float, so literally the same value and type as the proposed inf/Infinity builtin. The only way you could tell them apart is by identity tests.
which is the case for any other float -- or, indeed any other two instances of a type that have the same value.
It seems this idea has gotten a bit sidetracked by, shall we say, a lack of precision in the conversation. So a few points:
math.inf or numpy,inf or, indeed float('inf") are not a special type or special object or anything else. each of these produces exactly the same thing -- a float with a particular value.
I noted a comment here about how odd it was to constructing a float with a function call and a string: float('inf') , but that is no different than any other use of the float type object with a string: float('0.1') works just fine -- and has been pointed out, that's how you create Decimals and many other types as well.
So what IS special here? What's special is that we have a literal syntax for only a few special fundamental types: floats, ints, strings. (I htin that's it, yes?), as well as "display" versions of a few core container types: list, dict, etc.
So the limitation here is that floats have a literal, and can have a huge number of values, all of which can be created by a literal, except inf, -in, and NaN (and the special versions of NaN ...).
Is this a limitation? sure it is. Is it critically important? obviously not, people have been productive with Python for decades. Would it be nice and at least sometimes useful to be able to have a literal for inf and NaN? yes.
It's also the case that Python used to have even worse support for the float special values, there was PEP 754, which was rejected (notably due to lack of activity, not an all out rejection), but "Several ideas of this PEP were implemented for Python 2.6. float('inf') and repr(float('inf')) are now guaranteed to work on every supported platform with IEEE 754 semantics" -- which got us far enough.
So this is not the same as None, or adding True and False
So, I *think* what we are talking about here is not a "new" value or a new keyword, but rather an extension to what is considered a valid "literal". There may be technical limitations that I don't understand, but the proposal would be that the text ``inf`` and ``nan`` would be valid everywhere a float literal was valid, i.e.:
ast.literal_eval("inf") would produce a float with the IEEE inf value (similar for ``nan``) rather than being an error where it is now.
Would that require that it be a keyword? I don't think so, couldn't it be "just a name" in most contexts, like "True" was in py2, which did work in ast.literal_eval()? But if the only way to get them to be evaluated as literals would be to make them keywords, then this idea is dead in the water.
-CHB