On Sat, Sep 5, 2020 at 10:00 AM Steven D'Aprano <st...@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
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ZZ7NWLTALWSYA23IYVLKYKJKJK5ZLC2U/
Code of Conduct: http://python.org/psf/codeofconduct/
