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

[Thomas Bellman]

Alex Martelli <aleax at aleax.it> wrote:

> 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.

There are other ways.  Ways that do change the semantics of the
language somewhat, making it somewhat less dynamic, but my
understanding is that Guido is actually positive to doing so.

It is quite easy to determine whether some code modifies a
specific binding in its own local or global scope.  (The use of
'exec' would of course make the analyzer assume that the binding
*is* changed.)  You could then add the restriction that a module
may not change the bindings in another modules global or builtin
namespace.


> 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).

It almost sounds as if you are implying that doing analysis of
the entire program is something that is almost unheard of.  I
don't think you are actually meaning that, but for the benefit of
others, it might be worth noting that there have been compilers
that *do* data flow analysis on entire programs available for
several years now.  The MIPS C compiler, or rather the linker,
did global register allocation more than a decade ago, and since
then other compilers have done even more ambitious analysis of
entire programs.  I am under the impression that some LISP
compilers have done this too.

(But, yes, I do realize that it is more difficult to do this in a
dynamic language like Python than in a statically typed language
like C.)

If you, as I suspect, really mean that to implement this kind of
code analysis in Python is lots of hard work and involves lots of
trial-and-error testing to determine what is worth-while, then I
heartily agree.


> 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),

Note that I have no quibbles with this reasoning.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"You cannot achieve the impossible without   !  bellman @ lysator.liu.se
 attempting the absurd."                     !  Make Love -- Nicht Wahr!