True inconsistency in Python
radam2 at tampabay.rr.com
Tue Nov 18 00:06:39 CET 2003
On Mon, 17 Nov 2003 11:24:54 -0800, Erik Max Francis <max at alcyone.com>
>Ron Adam wrote:
>> To me the usefulness of using True and False is that it is defined to
>> values consistent with the programming language that you are using.
>I agree, insofar as the value of True and False as constants is that now
>have values set aside which mean _nothing_ but their Boolean values.
>This is very helpful for writing self-documenting code, something which
>I've always been a strong supporter of. If I have code where 0 or 1
>gets assigned to a variable, I'm going to have to look at the whole
>block to tell precisely what that's being used for: Is it a counter
>variable, a three-state value (say, -1, 0, and +1), is it an enumerated
>value type, or is it a Boolean? If I'm scanning code and I see
> x = True
>then I know right away that what I'm looking at is a variable used as a
>Boolean. (Of course, in proper self-documenting code, the variable
>would be named something more helpful than `x', but you see my point.)
>> So using them to assign x = True, or x = False. insures that when I
>> x = True
>> if x:
>> So I get consistent results for the language and platform I'm using
>> now and in the future. If down the road someone decided to make True
>> = 3, and False = -5, and they change the language so that any boolean
>> comparisons return 3 and -5 respectively, my use of True and False
>> will still work. If I tested for 1 or 0 using the 'if x:' method,
>> then my program will break.
>While this may be true in some sense, I don't think this is a powerful
>argument for using True/False. The chances of this happening are
>utterly remote, since it would break practically all code. (Obviously
>you weren't suggesting it was a real possibility given your choices of
>the alternate constants, but still.)
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 python you can change the value of True, or set True to point to
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.
>>>True = True
Ooops.... <wink> so much for that. So we need to do it this way.
>>>True = (1==1)
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
x = True
"lots of code"
True = 3 # as a programming error.
if (x == True): # evaluates as False!
or possibly this.....
True = 0 # another programming error
"lost of code"
x = True
if x: # evaluates as False again!
>I don't consider insulation from something utterly implausible happening
>very persuasive, since I'm not worried about that utterly implausible
>thing happening. I find explicit Boolean constants available for
>writing self-documenting code much more compelling.
The above is much less implausible. Do you agree?
More information about the Python-list