True inconsistency in Python

[Ron Adam]

On Mon, 17 Nov 2003 18:47:34 -0800, Erik Max Francis <max at alcyone.com>
wrote:

>Ron Adam wrote:
>
>> I'm not arguing at all.  Only exploring the issue.
>
>Maybe you should summarize your central tenets, I'm afraid they've
>gotten lost.  It seems like we've run around in a big circle.
>

I think so too.

My basic tenant,  belief,  or point,  is.

The main inconsistencies of 'True' and 'False'  are due to the
possibility of the names 'True' and 'False' being reassigned.

And the best way to fix this is by making 'True' and 'False'  literals
or constants.  


>Unless you're using naughty things like `from module import *', no
>collision can occur.  If you are, why are you more worried about
>collisions with the True/False constants, rather than any of the other
>builtins?  They're all just as possible.

It looks to me the benefits of changing this one item are worthwhile,
and the drawbacks if it very low.  It is also consistent to have them
as basic constants and/or literals in the same way digits and the
alphabet are.   The values True and False are to Type boo()  as digits
are to int() or floats(),  and as the alphabet is to string().   


>> So maybe you are correct, we shouldn't use anything.  (?)
>
>My point is that you need to expect a sane environment.  If you're
>working with fellow engineers who keep planting time bombs, maybe they
>should be removed from the team rather than having to defensively work
>around their potential disasters.

I expect a set of programmers that have many different skill levels.
With a lot of beginners,  a fair amount who are average,  a good
number who are above average,  and a small number who are experts.  


>Python has as a central concept that everyone's an adult.  If you want
>to mess things up really badly, you can.  If you want to use some clever
>trick in order to save a lot of work, you can do that too.  With power
>and flexibility comes the ability to mess things up really badly.  Lack
>of constants is an example of this idea in Python (as is, for example,
>the lack of access control on object attributes).

No not every one is an adult.  Python is being taught as a first
computer language in some high schools now.   I'm only suggesting that
this one item be changed here.  And that this change is beneficial
with very few if any drawbacks.  


>If someone's going to keep overriding True and False, or int, or open,
>then you're not going to get anywhere.  Python isn't designed so that
>you can write code that is completely protected from the misbehavior of
>other engineers.  And it shouldn't be.

Is python just for engineers?  I don't believe it is.


>> Yes,  so what are True and False?  Are they just preinitialized
>> variables?   Are do they have special properties of their own?
>
>They're builtins, just like all the other builtins like int, max, file,
>map, etc.
>

So they have not special property of there own.  From what I
understand,  being a built in is a matter of where the code is, and
doesn't have anything to do with what it does.  It's a practical
matter that the most frequently used items are built ins.

>> 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.
>
>All the other "preinitialized variables" have exactly the same
>characteristic.  There are no constants in Python.

Yes,  Other than the literals like the digits, and alphabetic
characters.  You can't change them.  Why not have True and False work
the same way?



>I never suggested that True and False shouldn't be used; far from it.  I
>just used your objection (that their values can be overridden) to
>illustrate a reductio ad absurdum.  

It was an observation,  not an objection.


>Either that's a really scary thing
>(which you can't defend against) and the interpreter comes crumbling
>down, or you assume that people are going to behave themselves and don't
>worry about it.

Or I don't assume anything, and realize both of those are
possibilities.  And with a large enough group of programmers,  they
will happen.   Although,  I think "the interpreter crumbling down" is
exaggerating a bit.  


>> If a programmer is malicious and wants to sabotage code, making True
>> and False constants will hardly stop them.
>
>Exactly.  So I don't understand what your point is; you're the one who
>brought up the danger of overriding True and False.

And you agree it is a danger.  Don't you?  That is my point.


>> 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.
>
>You've gotten severely sidetracked on this thread.  The original
>inconsistency mentioned in this thread is that explicit comparisons with
>True or False do not involve an implicit conversion to bool.  So 3 ==
>True is False, even though bool(3) == True is True.

Ok,  I see,  yes,  I missed that  part.  But this is consistent with
"if value:"  evaluating to True if it's not zero.   I understand it's
because of practical convenience that type bool is a subset of
integers,  and this is how bool should operate if bool is a subset of
integers and not a subset of type binary.  (if there were a type
binary in Python.)

My background is in digital electronics,  so I am aware this isn't a
true bool type and it varies from pure binary logic.  But it is
consistent,  and it does make sense to me.  

So the inconsistency I saw was in that True and False are not treated
the same as other types made up from literals.   1 is always equal to
1,  and it's never equal to 2.  The same can't be said for True and
False and bool(),  So doing comparisons to True is not as reliable as
adding digits, or constructing strings from the alphabet.  


>> Doing this causes an error:
>> 
>> >>> 1 = 2
>> SyntaxError: can't assign to literal
>> 
>> Doing this does not cause an error:
>> 
>> >>> True = False
>> >>>
>
>That's because a literal is not a name that can be assigned to, anymore
>than 
>
>	'asdf' = 2 + 3
>
>could possibly make any sense.  True and False are, on the other hand,
>names.

And my point is maybe they shouldn't be names,  but treated the same
as letters and numbers.    


>
>> Are True and False Bools?
>
>True and False are names which are initially bound to the true and false
>Boolean values, respectively.  They're names like any other names:  x,
>thisIsAVariable, int, str, sys, etc.
>
>> Why are they not also literals?  Wouldn't that be consistent?
>
>They're not literals because that's not the way that they're handled by
>the language.  None, for instance, is not a literal; it's a name.  So
>neither are True and False.

But that's not a reason, its a situation.  I know they are names.

Why could they not be made to be literals?  And why would we not want
them to be literals?  

Terry Reedy has pointed out to me that this will likely be changed in
the future.  I think it will make Python more consistent by preventing
the possible reassignments of True, False, and None.   If these values
are used throughout the libraries, reassigning them will cause
something to not work somewhere at sometime.  So preventing them from
being reassigned is practical also.

_Ronald Adam