Why is 'None' not assignable but 'True'/'False' are?

[Antoon Pardon]

On 2006-01-02, Alex Martelli <aleax at mail.comcast.net> wrote:
> Rodney Maxwell <rodney.maxwell at gmail.com> wrote:
>
>> In Python 2.4.1:
>> 
>> >>> None = 99
>> SyntaxError: assignment to None
>> >>> True = 99
>> >>> False = 99
>> >>> True == False
>> True
>> -----------------------
>> So why is 'None' special?
>
> A legacy/backwards compatibility issue: None has been there 'forever',
> so that no sensible code ever had any business assigning to it; but
> 'False' and 'True' were introduced just a few years ago, and it was
> important to not break sensible existing code doing something like
>
> True = 1
> False = 0
>
> at the very start.  In Python 3.0, when backwards compatibilities can be
> introduced, True and False will become keywords (as will None); see

I don't think it would be a good idea to make them keywords.

If you want to turn these into keywords, the question pops up, why
only these. Don't we see a lot of example code that goes like this:

  list = [ some, kind, of, list ]
  str = "some string"

And often enough it is followed with the advise not to shadow builtins.

So if python goes the route of keywords, it seems that all builtins
should be turned into keywords and not just a few of them. But that
would make it impossible to do things like obj.str, just as it is
now impossible to have something like obj.raise or obj.if

I think a way to make a name not rebindable in a specific namespace
would be more appropiate.

-- 
Antoon Pardon