Christopher Barker writes:
> But why are they keywords? In Py2, True and False were just identifiers-
> they were made keywords in py3.
>
> I’m suggesting that one reason that they were made keywords is that
> it's useful for them to be singletons, which is much harder to do
> (or at least use consistently) if the names can be reassigned.
Except that the obvious assignments are True = 1 and False = 0, which
both denote singletons (in CPython, anyway and as it happens).[1] That
is, since bool() returns only True and False, as long as you use only
those literals (0, False, 1, True) and bool(), "is" works as well as
"==". So it's reserving the names, not the "singleton-ness", that's
important.
I assume that what the advocates of a true Boolean type wanted was
{False, True} to be *disjoint* from the integers, so that "True is 1"
is false. In order to give them actual literal names (ie, compiling
to specific objects rather than to references to bindings), they
needed to be made keywords. The whole Boolean project makes little
sense unless the true and false objects have literal syntax, and in
Python that means keyword names.
> But these float special values can't be singletons anyway
Of course they *can*, they just aren't. There's no reason not to make
1e1000 is inf and (1e1000 - 1e999) is nan "work" (and it might even be
more efficient to special-case them and return singletons rather than
allocate objects and wrap them in floats -- if they were useful, but
they're not so why bother?)
But you don't want programmers doing something == nan or something ==
inf, either. For the former, they *have* to use math.isnan because of
how math.nan.__eq__ is defined (and of course the system is probably
delivering NaNs different from math.nan). The latter "works"
*because* inf is a specific value (in IEEE 754), but it's nonsense
interpreted as "infinity", since in Python it mostly denotes a value
for an expression whose computation overflowed at some point but in
many cases has a value in the real number system that is representable
as a float.
> Which means there really isn't a reason to make them keywords at
> all.
There's the same reason as for True and False: the principle that all
values of certain fundamental types should have fixed literal
representations in the language. The fact that there are other
objects that are equal to inf would be the same as bool: True is not 1
but True == 1.
> we would not want to [add new values of these types] even if it
> were even possible.
If you're referring to inf and nan, that's not clear. We could have
inf_unrepresentable and inf_denormalized_or_unrepresentable (the
latter would be used if you want any loss of precision due to "near"
overflow to be considered inf), and nan_quiet and nan_signaling, so
that operations that in math result in a NaN will all either have a
NaN value which propagates or result in an immediate exception,
depending on whether nan is the former or the latter.[2] I guess you
could look at NumPy and friends for evidence whether those
distinctions are ever worth making in Python programs, but at least in
theory they're possibly useful.
As for Booleans, Goedel showed that a consistent logic sufficient to
support proving theorems of arithmetic is inherently 3-valued:
A is True, A is False, A is Undecidable.
But Goedel's logic is unimplementable in our computers by the very
definition of undecidable. Some of the most subtle Buddhist texts are
well-rationalized by a logic with four truth values for A:
A is True, A is False, A is neither True nor False, A is both True
and False.
Some Buddhists are very tolerant, they accept inconsistent logics. Of
course, we probably don't want to use those logics in computers. :-)
Footnotes:
[1] I'm not saying that the integer 1 is a singleton; it's not, there
can be many distinct int objects equal to 1. I'm saying that the int
denoted by "1" in a Python program is a singleton.
[2] Of course these distinctions can't be made in plain Python, but
they can be made from C extensions.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/43KEPOUJXAXW7YI5BYCK2PTASKL657SY/
Code of Conduct: http://python.org/psf/codeofconduct/
