True inconsistency in Python

[Ron Adam]

On Mon, 17 Nov 2003 11:24:54 -0800, Erik Max Francis <max at alcyone.com>
wrote:

>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
>> do:
>> 
>>         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
something different.

For example you can do this.

>>> True
True
>>> False
False
>>> True = False
>>> 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
>>>True
False

Ooops.... <wink>  so much for that.   So we need to do it this way.

>>>True = (1==1)
>>>True
True


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. 

x = True

"lots of code"

True = 3		# as a programming error.

"more code"

if  (x == True):		# evaluates as False!
	print True
else:
	print False


or possibly this.....


True = 0		# another programming error

"lost of code"

x = True
if x:			# evaluates as False again!
	print True
else:
	print False


>
>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?


_Ronald Adam