True inconsistency in Python

[Ron Adam]

On Mon, 17 Nov 2003 15:37:41 -0800, Erik Max Francis <max at alcyone.com>
wrote:

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

I'm not arguing at all.  Only exploring the issue.  

I don't know if we should never use True and False.  It's as
dependable as any other variables and we need to handle them in the
same way.  That includes making sure they have not been changed if we
use them for something that can be a mission critical application.
ie...  

True = (1==1)
False = (1!=1)

or if you prefer;

True = bool(1)
False = bool(0)

The interpreter initializes True and False when it starts.  So for
small applications, they are fairly dependable, it shouldn't be a
problem to use them.  For large application with multiple files
imported into them written by several programmers, it might not be a
bad idea to initialize them like above to be safe.

This of course is why they are constants in other languages.  It
increases the dependability of the code.  Both by using True and False
and by making sure they cannot be changed.

>Of course, the fact that any builtin can be overridden sort of dulls
>that point, since that means you shouldn't use _anything_.

It may be beneficial to make changes to built in's not so easy in some
cases.  

>>> int(2.3)
2
>>> def int():
	return 32

>>> int(2.3)

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in -toplevel-
    int(2.3)
TypeError: int() takes no arguments (1 given)
>>> 


So maybe you are correct, we shouldn't use anything.  (?)

Being able to change things in Python is one of the reasons that makes
it powerful,  but being able to depend on certain things being
consistent is also a good thing.   So where do these intersect?  What
is the optimum mix of the two?


>> 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....
>
>Sure, but that's got nothing to do with True or False as specific
>entities.  This can happen with any builtin function, even the
>type/converters:

Yes,  so what are True and False?  Are they just preinitialized
variables?   Are do they have special properties of their own?  

>From what I've seen so far, the 'True' and 'False' values are useful,
but the names 'True' and 'False' can be changed and aren't synonymous
with the values 'True' and 'False'.   Two different things.

So how would you use True and False?   I say go ahead  and use them to
make your code readable,  but if its a large or mission critical
application,  you might want to make sure they are what they should be
before you do by initializing them the same as you would any other
variable.


>
>>>> 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
>or False.

If a programmer is malicious and wants to sabotage code, making True
and False constants will hardly stop them.   

>So how does this point relate to explicit testing against the values of
>True or False
>

Well if True and False can be changed,  then it really isn't an
explicit test is it?   It's a relative test.  

if you want to test if a value is explicitly equal to 'True',  you
need to use (value == (1==1)).

And if you want to explicitly test if something is equal to 'false',
use (value ==(1!=1)).

These will always work.   And  doing:

if x:            # x is not 'False'

is not the same as:

if x=True:

This is because Bools are a subset of ints and not a subset of binary
as in some other languages.  If they were a subset of binary,  they
would be equivalent.   We just need to be aware of that.  Bools as a
subset of ints give the advantage of 'if x:'. where x is true if its
not 0 instead of x only being "True" if it's equal to 1.  

I'm probably repeating what's already been said in this thread
already.


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

What am I missing?  The thread is about 'True inconsistency in
Python', and the reason it's inconsistent is because it can be changed
so easy.  

Doing this causes an error:

>>> 1 = 2
SyntaxError: can't assign to literal


Doing this does not cause an error:

>>> True = False
>>> 

Are True and False Bools?

Why are they not also literals?  Wouldn't that be consistent?


_Ronald Adam