True inconsistency in Python

[Ron Adam]

The developers agree and would make them so now if it were not for
backward compatibility needs. They probably will make them so in the
future. Currently, reassigning None can get you a Warning.

That would be good.

When the bool type was added, a few people argued for a pure bool type
with no relation to anything else. However, in Python, 'practicality
beats purity'. Having True/False == 1/0 now and forever has practical
uses.

Good also.

Yes, you are currently allowed to stab yourself in the back (but even
this will probably change in the future). Don't do it.

I agree, it's good that it may change.

In 2.2.2+, you only need to not change them and to not work with a
psycopath.

Many people are starting to learn programming with python as their
first computer language. I wouldn't refer to them as a psychopath.
They may one day write programs that save peoples lives. They have to
start someplace. Many people using python will not be professional
programmers but enthusiast and hobbiests, or web page programmers,
or ..... in other words, a very large and diverse group.

...

Yes, it is more plausible that you shoot yourself in the feet than
that Guido and the whole Python development community go bonkers. I
strongly suspect that PyChecker can check for assignments to True and
False (along with about a hundred other things). Get it and use it.

Terry J. Reedy

I'm not sure what your point is here, but using PyChecker sounds like
a good suggestion.

_Ronald Adam

 

[Ron Adam]

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

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.

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.

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.

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.

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.

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.

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.


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

 

[Erik Max Francis]

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.

But True and False are no different from None, int, str, or any of the
other builtins.

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

But, as I said, you're not going to run into this problem unless you're
doing unsafe things already (like `from module import *'), or letting
people you don't trust edit your source. I don't see this as a big
problem.

Accidental rebindings of things like int, str, and other builtin
types/functions with common names seem _far_ more common than
"accidentally" rebinding True or False.

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.

Yes. And builtins other than True and False are far more frequently
accidentally rebound.

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(),

It's not true for int, either.

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.

It will change in the sense that rebinding these names may result in
warnings or errors (already there's a warning for rebinding None in the
usual way), not that they'll become literals.

--
Erik Max Francis && (e-mail address removed) && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ God will forgive me; that's his business.
-- Heinrich Heine

 

[Terry Reedy]

What if the expression is 37 lines long?

Given that

if <horrendous long expression

is *exactly equivalent* to

if True == <horrendous long expression

I see no reason for the latter and a big reason against it: adding
'True==' deceptively implies that there is some difference to justify
the extra chars. I get the feeling you actually somehow believe that
there is a difference.

Would you advocate that sums and products always start (or end) with
an analogous and explicit '0+' or '1*'? What would you think of a
style guide that mandated code like the following:

x = (0+0j) + a + b
y = 1.0 * d * e

These have been occasionally used to force result type. 'True==' also
forces, as an alternative to bool(), but if bool() is redundant, as it
is in Python for conditional expressions, so is 'True =='.

Terry J. Reedy

 

[Terry Reedy]

I believe the words 'True' and 'False' need to be treated the same as
the digits 1, 2, 3, ... The values of the digits do not change. We
depend on them not changing.
True should always evaluate to True also.
So we can depend on it as well.
This is my opinion, you don't have to agree with it.

Others have also proposed that None, True, and False be made keywords.
We'll see how far Guido goes in 3.0. I do not think even he really
knows.

It looks to me that 'True' in python is a combination of the boolean
binary logic of 1 or 0, and as an "exists" test of 0 or not 0.

[me]
I do not understand this. If you have a reference to 0, then 0
exists. If you do not, then the 'existence' or not of an int with
value 0 is irrelevant.

if x: is a test to see if the value 0 does not exist in x.

Aha. Got it. Above, you are using 'exist' at a different level of
abstraction than I understood. I was thinking of object or binding
existence, whereas you were speaking of value connotation. Yes, if c
is a count of something, then 'if c:' tests for the positive existence
of at least one counted something. Similarly for list L of
somethings, 'if L:' tests for the existence of at least one listed
something.

I consider this 'overloading' of conditional expressions to be one of
the great features of Python. I now take it for granted.

Yes, you understand.

Whoops, now you are agreeing with 'exist' as 'binding existence'.
Yes, this is a 'divergence' from your other sense of exist.

Yes, I noticed. The reason I bring this up is in situations where
you want to initialize a variable if it has not been defined yet, but
do not want to re initialize it if it's already been defined.

For just one variable, I might use

try: x
except NameError: x = 'value'

Terry J. Reedy

 

[Terry Reedy]

Many people are starting to learn programming with python as their
first computer language. I wouldn't refer to them as a psychopath.

Neither would I. I was thinking of the following scenario. You are
part of a programming group. You write module ronad, to be imported
by danor written by 'Dan Oreo'. Psycho writes unrelated module
'sneaky' with

import ronad
ronad.True, ronad.False = False, True

perhaps disguised. You get blamed for the 'bug' that you did not
write and cannot find.

[Prohibiting this scenario (import module and mask builtins there in)
has been suggested. I believe it was once approved and is still under
consideration but the change has the problem that there seem to be
legitimate uses.]

They may one day write programs that save peoples lives. They have to
start someplace. Many people using python will not be professional
programmers but enthusiast and hobbiests, or web page programmers,
or ..... in other words, a very large and diverse group.

People often post code redefining builtings like file and list, and
get reminders not to do so. I cannot remember anyone accidentally
overwriting True or False.

....

I'm not sure what your point is here, but using PyChecker sounds like
a good suggestion.

That suggestion was my final point. Ignore the warm-up pitch.

Terry J. Reedy

 

[Ron Adam]

[Prohibiting this scenario (import module and mask builtins there in)
has been suggested. I believe it was once approved and is still under
consideration but the change has the problem that there seem to be
legitimate uses.]

It might conflict with existing programs that assign 'True = 1' and
'False = 0', I can see where that could be a very common
occurrence for people who are new to Python. And once they learn
about the True and False values, they may not go back and change the
older programs. ie... if it'n not broke don't fix it. In other
words, they leave them as is and move on to the next project.

_Ronald Adam