True inconsistency in Python

[Erik Max Francis]

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.

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

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.

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

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

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.

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

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

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

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

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

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

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

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

-- 
   Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
 __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/  \ 
\__/ So little time, so little to do.
    -- Oscar Levant