True inconsistency in Python
Erik Max Francis
max at alcyone.com
Tue Nov 18 00:37:41 CET 2003
Ron Adam wrote:
> 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. Their actual internal
> values shouldn't be relevant or depended on. They need to be constant
> to how a boolean expression evaluates in the language they are in.
In effect you are arguing against the point you were trumpeting earlier.
If we take your argument to its logical conclusion, that means that True
and False may be modified (accidentally or intentionally) by a
programmer and so we should never rely on its value. Which means that
you should never use True or False.
Of course, the fact that any builtin can be overridden sort of dulls
that point, since that means you shouldn't use _anything_.
> In python you can change the value of True, or set True to point to
> something different.
> For example you can do this.
> >>> True
> >>> False
> >>> True = False
> >>> True
> Now all bets are off....
Sure, but that's got nothing to do with True or False as specific
entities. This can happen with any builtin function, even the
>>> int = float
>>> float = str
>>> str = lambda x: None
>>> file = 'elif'
Since these can happen with any of these things, singling out True and
False doesn't make sense.
> True should be a Constant and always equal to (1==1) and False should
> always be equal to (1!=1). It's not, so we need to be careful
> using True.
I really don't see your point here. It's true that someone malicious or
insufficiently careful can override the values of "constants" like True
or False. Of course that's true with all the other builtin functions,
constants, and types, so that point really has nothing to do with True
So how does this point relate to explicit testing against the values of
True or False
> The above is much less implausible. Do you agree?
Yes, but it is still programmer error. If `str' got overridden -- quite
frankly, a much more common programmer error -- you'd have the same
problem, and it has nothing to do with Booleans.
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ And there inside our private war / I died the night before
More information about the Python-list