True inconsistency in Python

Terry Reedy tjreedy at
Tue Nov 18 05:40:52 CET 2003

"Ron Adam" <radam2 at> wrote in message
news:8qhirvgi2sf5l3vkfocq65mcb94c6pbb9s at
> No, this one point is not the only reason,  I made the example a
> little farfetched to demonstrate a concept I think is a valid reason
> to have 'True' and 'False' as Constants.

The developers agree and would make them so now if it were not for
backward compatibility needs.  They probably will make them so in the
future.  Currently, reassigning None can get you a Warning.

> Their actual internal
> values shouldn't be relevant or depended on.

When the bool type was added, a few people argued for a pure bool type
with no relation to anything else.  However, in Python, 'practicality
beats purity'.  Having True/False == 1/0 now and forever has practical

> In python you can change the value of True, or set True to point to
> something different.

Yes, you are currently allowed to stab yourself in the back (but even
this will probably change in the future).  Don't do it.

> For example you can do this.
> >>> True = False
> Now all bets are off....


> To be sure that True is True and False is
> False,  we need to put in explicit definitions into our programs.

In 2.2.2+, you only need to not change them and to not work with a

> The above is much less implausible.  Do you agree?

Yes, it is more plausible that you shoot yourself in the feet than
that Guido and the whole Python development community go bonkers.  I
strongly suspect that PyChecker can check for assignments to True and
False (along with about a hundred other things).  Get it and use it.

Terry J. Reedy

More information about the Python-list mailing list