On 2006-01-02, Alex Martelli <[EMAIL PROTECTED]> wrote: > Rodney Maxwell <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
