True, False, None (was re. Pruss's manifesto)

[Alex Martelli]

Thomas Bellman wrote:

> Alex Martelli <aleax at aleax.it> wrote:
> 
>> True, False and None may well become keywords in the future, because that
>> might make things "even finer" in some respects.  E.g., right now,
>>     while True:
>>         ...
>> has to look-up 'True' at EACH step just in case the ... code rebinds
>> that name.  This _is_ a bit silly, when there is no real use-case for
>> "letting True be re-bound".  Nothing major, but...:
> 
> That's a silly reason to make them keywords.  A much better way
> to achieve the same goal would be to make the optimizer recognize
> that True isn't re-bound within the loop.  Making the optimizer
> better would improve the performance of much more code than just
> 'while True' loops.

You are heartily welcome to perform the dynamic whole-code analysis
needed to prove whether True (or any other built-in identifier) may
or not be re-bound as a side effect of functions called within the
loop -- including the calls to methods that can be performed by just
about every operation in the language.  It seems a very worthy
research project, which might take good advantage of the results
of the pypy project (there is plenty of such advanced research that
is scheduled to take place as part of pypy, but there is also surely
space for a lot of other such projects; few are going to bear fruit,
after all, so, the more are started, the merrier).

Meanwhile, during the years in which this advanced research project
of yours matures and (with luck) produces usable results, Python's
mainstream implementation will stick to the general strategy that has 
served it so well and for so long: _simplicity_ first and foremost,
optimization (and thus complication) only where it has provable great
benefit/cost ratios (e.g., dictionary access and list-sorting).

As there is really no good use case for letting user code rebind the
built-in names None, True, and False, making them keywords has almost
only pluses (the "almost" being related to backwards compatibility
issues), as does "nailing down" many other popular built-in names (by
techniques different from making them into keywords, most likely, as
the tradeoffs are quite different in those cases).

The process has already begun in Python 2.3, mind you...:

[alex at lancelot bo]$ python2.3 -c 'None=23'
<string>:1: SyntaxWarning: assignment to None

(True and False will take more time, because a program may try to
assign them [if not already known] in order to be compatible with
relatively recent Python releases which did not have them as
built-in names).


Alex