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

[Alex Martelli]

Thomas Bellman wrote:

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

Yes, for other built-ins.  Not for these -- try assigning to None in Python 
2.3 and see the warning.  There's just NO use case for supporting None
being assigned to, thus, that was put in immediately; True and False need
to remain syntactically assignable for a while to support code that 
_conditionally_ assigns them if they're not already defined, but while it's
therefore unacceptable to have such assignments give _syntax_ errors or 
warnings, for the moment, they can nevertheless be blocked (and warned 
against) at runtime whenever Guido thinks that's opportune.


> It almost sounds as if you are implying that doing analysis of
> the entire program is something that is almost unheard of.  I

Oh, no, I do remember when it was a brand-new novelty in a
production compiler (exactly the MIPS one, on DEC workstations
I believe).  Absolutely unusable for any program above toy-level,
of course -- and when we got shiny new workstations twice as
fast as the previous ones, it barely made a dent in the size of
programs it could deal with, since apparently the resources it
consumed went up exponentially with program size.  We gritted
our teeth and let it run for some humungous time on the smallest
of the applications we sold, thinking that we'd measure the real
effects and see if it was worth restructuring all of our production
environment around such times.

We never found out what benefits whole-program analysis might
have given, because the resulting program was so bug-ridden it
couldn't perform ANY user-level task in our field (mechanical CAD).
Shutting off the whole-program optimizations gave us a perfectly
usable program, of course, just as we had on every other platform
we supported (a dozen at that time); they were _all_ "whole-program 
analysis" bugs.  That was basically the end of my interest in the issue
(that was supposed to be a _production_ compiler, it had been years
in research and beta stages already, as I recall...!)

The concept of turning Python's super-lightweight, lightning-fast,
"i don't even _peephole_ optimize" compiler into any semblance of
such a monster, in order to let people code "None=23" rather than
making None a keyword (etc), is _truly_ a hoot.  (I realize that's
not what you're advocating, thanks to your clarification at the end,
but the incongruity of the image is still worth at least a smile).


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

It's a nightmare to do it right for C, and I don't think any production
compiler currently claims to do it (MIPS went up in flames -- pity for
their chips, but their whole-program-analyzer is one thing I _don't_ 
miss:-).  Languages such as Haskell, with a much cleaner and rigid 
design, maybe.  


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

I don't have to spend lots of hard work to determine that _any_
substantial complication of the compiler for the purpose of letting
somebody code "None=23" is _not_ worthwhile.  As for the various
possibilities regarding _optimization_ (which have nothing to do with
wanting to allow assignments to None etc), one of pypy's motivations
is exactly to make such experimentation much easier.  But I don't
expect such research to turn into production-use technology in the
bat of an eye.


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

Oh good.  "We'll design the language any which way and incredibly
smart optimizers will take care of the rest" has never been Python's
philosophy, and I think its emphasis of simplicity _including simplicity
of implementation_ has served it very well and it would be foolhardy
to chuck it away.


Alex