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

[Rodney Maxwell]

In Python 2.4.1:
True

 

[Alex Martelli]

In Python 2.4.1:

True

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
<http://www.python.org/peps/pep-3000.html>.


Alex

 

[Antoon Pardon]

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.