True inconsistency in Python

[Erik Max Francis]

Re: True inconsistency in Python

Ron Adam wrote:
[color=blue]
> 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.[/color]

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.

Of course, the fact that any builtin can be overridden sort of dulls
that point, since that means you shouldn't use _anything_.
[color=blue]
> In python you can change the value of True, or set True to point to
> something different.
>
> For example you can do this.
>[color=green][color=darkred]
> >>> True[/color][/color]
> True[color=green][color=darkred]
> >>> False[/color][/color]
> False[color=green][color=darkred]
> >>> True = False
> >>> True[/color][/color]
> False
>
> Now all bets are off....[/color]

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:
[color=blue][color=green][color=darkred]
>>> int = float
>>> float = str
>>> str = lambda x: None
>>> file = 'elif'[/color][/color][/color]

Since these can happen with any of these things, singling out True and
False doesn't make sense.
[color=blue]
> 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.[/color]

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.

So how does this point relate to explicit testing against the values of
True or False
[color=blue]
> The above is much less implausible. Do you agree?[/color]

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.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ And there inside our private war / I died the night before
-- Sade

[KefX]

Re: True inconsistency in Python

[color=blue]
>Yes. The same cascade into insanity developes. If you're testing for
>falsity, why not write x == false? But what about _that_ test,
>shouldn't that be (x == false) != false? And _that_ test ...
>[/color]

Of course the point that those tests aren't any less redundant from the
language perspective is valid. But they're a heck of a lot more redundant to a
human reader than a single "== false".
[color=blue]
>My point is that any such coding standard is dumb.[/color]

In my experience, every coding standard has things one would call "dumb". But
not everybody calls the same thing dumb. (I remember some people objecting to
my assertion that "assert" should be used as often to check parameters in C
code when defining functions...I still don't get how that's dumb. Some even
claimed that assert was a C++ thing!)
[color=blue][color=green]
>> But if whatever goes in "blah" is really long (and often it is), you
>> very
>> quickly see what is being compared: it's a straight boolean
>> comparison, whereas
>> with the second you have to look at the whole thing, find no
>> comparison
>> operator, and go, "oh, there's no explicit comparison so it's
>> obviously an
>> implicit straight boolean comparison".[/color]
>
>I don't see the value in this. The expression in an if statement is
>treated as a Boolean expression. In languages where there isn't a
>distinct Boolean type without implicit conversions (like your example,
>C89), it doesn't matter whether you put the explicit comparison there or
>not. However long the expression is, I don't see how adding `== true'
>at the end makes it more clear.[/color]

What if the expression is 37 lines long? (Can't happen? I'm LOOKING at such an
example!) Fishing out the main comparison in such a monster isn't always the
easiest thing to do. Of course I'm exaggerating here, since we usually don't
write 37-line expressions, but still.
[color=blue]
>It's a Boolean test, what's to make
>explicit?[/color]

Yes, all tests are boolean tests in the sense that they evaluate to a bool and
the if statement then compares the result, but not all comparisons are boolean
comparisons in the sense that we don't always compare to a boolean value. In
other words, "a == 0" isn't comparing against true or false, it's comparing
against an integer. It's worth noting here that omitting the "== 0" here is
considered bad style by many (though this is by no means universal). The camp
that would have you write "== false" invariably falls in the same camp that
would have you write "== 0", because that way the two would be consistent in
that you always specify what's being compared to what. Of course, this doesn't
mean everybody would have you write "== 0" would also have you write "==
false". The idea is consistency (I don't know how that slipped my mind in my
original posting.)
[color=blue]
>All including the explicit test there does is make other programmers
>wonder if you've lost your mind[/color]

Not all programmers would think that, again. :)
[color=blue]
>Trying to correct that error, you end up with monstrosities such
>as bool(x) == True or operator.truth( x) == True (or the equivalent in
>other languages), and after some point it should dawn on the programmer
>that the explicit True test is pointless.[/color]

I don't see how that would logically follow just from making an explicit bool
test. We know that such code is broken when we consider it, and then we reject
it, and we just do it the way we always did it, whether that's omitting the
explicit comparison altogether or comparing against false, or whatever other
possibility.

- Kef

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 15:37:41 -0800, Erik Max Francis <max@alcyone.co m>
wrote:
[color=blue]
>Ron Adam wrote:
>[color=green]
>> 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.[/color]
>
>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.[/color]

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.
[color=blue]
>Of course, the fact that any builtin can be overridden sort of dulls
>that point, since that means you shouldn't use _anything_.[/color]

It may be beneficial to make changes to built in's not so easy in some
cases.
[color=blue][color=green][color=darkred]
>>> int(2.3)[/color][/color][/color]
2[color=blue][color=green][color=darkred]
>>> def int():[/color][/color][/color]
return 32
[color=blue][color=green][color=darkred]
>>> int(2.3)[/color][/color][/color]

Traceback (most recent call last):
File "<pyshell#4 >", line 1, in -toplevel-
int(2.3)
TypeError: int() takes no arguments (1 given)[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]


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?

[color=blue][color=green]
>> In python you can change the value of True, or set True to point to
>> something different.
>>
>> For example you can do this.
>>[color=darkred]
>> >>> True[/color]
>> True[color=darkred]
>> >>> False[/color]
>> False[color=darkred]
>> >>> True = False
>> >>> True[/color]
>> False
>>
>> Now all bets are off....[/color]
>
>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:[/color]

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.

[color=blue]
>[color=green][color=darkred]
>>>> int = float
>>>> float = str
>>>> str = lambda x: None
>>>> file = 'elif'[/color][/color]
>
>Since these can happen with any of these things, singling out True and
>False doesn't make sense.
>[color=green]
>> 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.[/color]
>
>I really don't see your point here. It's true that someone malicious or
>insufficient ly 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.[/color]

If a programmer is malicious and wants to sabotage code, making True
and False constants will hardly stop them.
[color=blue]
>So how does this point relate to explicit testing against the values of
>True or False
>[/color]

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.

[color=blue][color=green]
>> The above is much less implausible. Do you agree?[/color]
>
>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.[/color]

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:
[color=blue][color=green][color=darkred]
>>> 1 = 2[/color][/color][/color]
SyntaxError: can't assign to literal


Doing this does not cause an error:
[color=blue][color=green][color=darkred]
>>> True = False
>>>[/color][/color][/color]

Are True and False Bools?

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


_Ronald Adam

[Ben Finney]

Re: True inconsistency in Python

On 18 Nov 2003 01:11:13 GMT, KefX wrote:[color=blue]
> un-attributed author wrote:[color=green]
>>I don't see the value in this. The expression in an if statement is
>>treated as a Boolean expression. [...]
>>However long the expression is, I don't see how adding `== true' at
>>the end makes it more clear.[/color]
>
> What if the expression is 37 lines long?[/color]

What of it? Is a long expression in an 'if' statement somehow less
likely to be treated as Boolean? What does appending ' == True' gain?
How could it not be obvious that the entire expression will be evaluated
for Boolean truth, when the expression is the argument to 'if' ?
[color=blue]
> Fishing out the main comparison in such a monster isn't always the
> easiest thing to do.[/color]

How does "fishing out the main comparison" have anything to do with
appending ' == True' to the expression?
[color=blue]
> "a == 0" isn't comparing against true or false, it's comparing against
> an integer.[/color]

Correct. The comparison, though, is a Boolean expression, which will
evaluate to either True or False. Its use in an 'if' statement will
always evaluate it this way.
[color=blue]
> It's worth noting here that omitting the "== 0" here is
> considered bad style by many (though this is by no means universal).[/color]

Only in cases where ' == 0' is *not* a test for Boolean falsity.
Compare a variable against 0 if you want to test if its value is
numerically zero; evaluate the variable if it is supposed to contain a
Boolean true or false value.
[color=blue]
> The camp that would have you write "== false" invariably falls in the
> same camp that would have you write "== 0", because that way the two
> would be consistent in that you always specify what's being compared
> to what.[/color]

No. The argument to 'if' is a Boolean expression. A test against
numeric zero is not the same as a test against Boolean false, except by
implementation coincidence.

If the variable 'a' is conceptually containing a numeric value, then
using it as a Boolean value implies things that are not necessarily true
about the Boolean implementation. Hence, 'if( a == 0 )' and not
'if( ( a == 0 ) == True )'. Similarly, testing the negative case is
'if( not ( a == 0 ) )'. No explicit comparison to True or False is
required.

If the variable 'a' is conceptually containing a Boolean value, then
using it as the argument to 'if' is consistent. Hence, 'if( a )' and
not 'if( a == True )'. Similarly, testing the negative case is
'if( not a )'. No explicit comparison to True or False is required.

Once the expression *reads as a Boolean expression*, then adding further
comparisons against Boolean values helps nothing.
[color=blue]
> The idea is consistency (I don't know how that slipped my mind in my
> original posting.)[/color]

I, too, value consistency, which is why I abhor adding ' == True' to
some Boolean expressions but not to others. It should be added to none
of them.

You appear to want semantic consistency between types (integer and
Boolean) that *by design* aren't semantically consistent. The 'if'
statement takes a Boolean expression as argument; to be consistent, one
passes it a Boolean expression argument, not some other type of
argument.

--
\ "A celebrity is one who is known by many people he is glad he |
`\ doesn't know." -- Henry L. Mencken |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Erik Max Francis]

Re: True inconsistency in Python

KefX wrote:
[color=blue]
> What if the expression is 37 lines long? (Can't happen? I'm LOOKING at
> such an
> example!) Fishing out the main comparison in such a monster isn't
> always the
> easiest thing to do. Of course I'm exaggerating here, since we usually
> don't
> write 37-line expressions, but still.[/color]

What if it's twenty pages long? I still don't see the benefit. If
you're looking at an expression in an if statement, you need to look at
the _whole_ expression to figure out what it's doing. I don't see how
ending it with `== True' makes it any more readable.
[color=blue]
> Yes, all tests are boolean tests in the sense that they evaluate to a
> bool and
> the if statement then compares the result, but not all comparisons are
> boolean
> comparisons in the sense that we don't always compare to a boolean
> value. In
> other words, "a == 0" isn't comparing against true or false, it's
> comparing
> against an integer. It's worth noting here that omitting the "== 0"
> here is
> considered bad style by many (though this is by no means universal).[/color]

Well, if you leave off the `== 0', it means something else.
[color=blue]
> The camp
> that would have you write "== false" invariably falls in the same camp
> that
> would have you write "== 0", because that way the two would be
> consistent in
> that you always specify what's being compared to what.[/color]

Not even a little. An explicit test for an individual value is one
thing. An explicit comparison for an individual value _when there are
only two possible categories_ (true or false) is utterly pointless,
because all it does is add the opportunity to create an error.
[color=blue]
> Of course, this
> doesn't
> mean everybody would have you write "== 0" would also have you write
> "==
> false". The idea is consistency (I don't know how that slipped my mind
> in my
> original posting.)[/color]

It's not at all consistent, that's the problem. Not to mention the
fact, as others pointed out, that not all false values are False.
[color=blue]
> I don't see how that would logically follow just from making an
> explicit bool
> test.[/color]

Because in Python the explicit Boolean test cannot possibly be anything
other than redundant. If it is not redundant, it is probably an error.

--
Erik Max Francis && max@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

[Erik Max Francis]

Re: True inconsistency in Python

Ron Adam wrote:
[color=blue]
> I'm not arguing at all. Only exploring the issue.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> So maybe you are correct, we shouldn't use anything. (?)[/color]

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.
[color=blue]
> Yes, so what are True and False? Are they just preinitialized
> variables? Are do they have special properties of their own?[/color]

They're builtins, just like all the other builtins like int, max, file,
map, etc.
[color=blue]
> 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.[/color]

All the other "preinitial ized variables" have exactly the same
characteristic. There are no constants in Python.
[color=blue]
> 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.[/color]

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.
[color=blue]
> If a programmer is malicious and wants to sabotage code, making True
> and False constants will hardly stop them.[/color]

Exactly. So I don't understand what your point is; you're the one who
brought up the danger of overriding True and False.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Doing this causes an error:
>[color=green][color=darkred]
> >>> 1 = 2[/color][/color]
> SyntaxError: can't assign to literal
>
> Doing this does not cause an error:
>[color=green][color=darkred]
> >>> True = False
> >>>[/color][/color][/color]

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.
[color=blue]
> Are True and False Bools?[/color]

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.
[color=blue]
> Why are they not also literals? Wouldn't that be consistent?[/color]

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

[Terry Reedy]

Re: True inconsistency in Python


"Ron Adam" <radam2@tampaba y.rr.com> wrote in message
news:ivqhrv403o r6mm68arqg5793g naaehjq8e@4ax.c om...[color=blue]
> x = True
> if x:
> ....[/color]

since the above snippert is equivalent to

if True:
....

which is equivalent to

....

you must have meant something more imvolved. But I am having trouble
filling in the missing pieces.
[color=blue]
> 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[/color]
True[color=blue]
> = 3, and False = -5, and they change the language so that any[/color]
boolean[color=blue]
> comparisons return 3 and -5 respectively, my use of True and False
> will still work.[/color]

This strikes me as comparable to worrying about being killed by an
asteroid. Is there some actual historical event that makes it more
plausible to you?

'Someone' would have to be someone with the authority to make such a
change in either the language or a particular implementation thereof.
Such people are usually at least somewhat sane. If someone did make
such a lunatic change, I suspect that it would not be the only one,
and one would have to be a lunatic to keep using that
language/implementation for serious work. Unless the language were
locked up and proprietary, users could reject such a change anyway.
(On the other hand, exposure to lesser lunacies *is* one of the risks
of using proprietary unclonible systems.)

....[color=blue]
> 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.[/color]

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.
[color=blue]
> If python had an exists operator, you could do.[/color]

I think you are confusing names and objects. You can only apply an
operator to objects and only to objects that exist.
[color=blue]
> if x exists:
> 'do something'[/color]

Do you mean
if bound_to_someth ing('x'): <do something>
?

Normally, in the absence of error, one only uses names that one has
defined (bound to somethingj). So you must be worried about the
following scenario:

if a: x=1
<more code>
if exists(x): <do something with x>

In non-module script only:
import __main__ as mm
x = 1
hasattr(mm, 'x') # True
hasattr(mm, 'y') # False

Anywhere: use try ... except NameError

Or, don't do that (have conditionally defined name). Instead,

x=None
if a: x = something_not_N one()
<more code>
if x != None: <do something with x>

In other words, name != None is often idiom for exists('name')!
[color=blue]
> This could serve two options also... does the object exist?[/color]

Again, Python only operates on objects that do exist.

....[color=blue]
> With pythons dynamic variables, I think an exists function would be
> useful to check if an object exists.[/color]

Same comment.

Terry J. Reedy

[Terry Reedy]

Re: True inconsistency in Python


"Ron Adam" <radam2@tampaba y.rr.com> wrote in message
news:8qhirvgi2s f5l3vkfocq65mcb 94c6pbb9s@4ax.c om...[color=blue]
> 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.[/color]

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.
[color=blue]
> Their actual internal
> values shouldn't be relevant or depended on.[/color]

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.
[color=blue]
> In python you can change the value of True, or set True to point to
> something different.[/color]

Yes, you are currently allowed to stab yourself in the back (but even
this will probably change in the future). Don't do it.
[color=blue]
> For example you can do this.[color=green][color=darkred]
> >>> True = False[/color][/color]
> Now all bets are off....[/color]

Ditto.
[color=blue]
> To be sure that True is True and False is
> False, we need to put in explicit definitions into our programs.[/color]

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

....[color=blue]
> The above is much less implausible. Do you agree?[/color]

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

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 23:13:24 -0500, "Terry Reedy" <tjreedy@udel.e du>
wrote:
[color=blue]
>
>"Ron Adam" <radam2@tampaba y.rr.com> wrote in message
>news:ivqhrv403 or6mm68arqg5793 gnaaehjq8e@4ax. com...[color=green]
>> x = True
>> if x:
>> ....[/color]
>
>since the above snippert is equivalent to
>
>if True:
>...
>
>which is equivalent to
>
>...
>
>you must have meant something more imvolved. But I am having trouble
>filling in the missing pieces.
>[/color]

Yes, the paragraph (that you snipped) above this code snippit,
explained that you need to be able to depend on 'True' being
consistent with how the underlying operating system evaluates boolean
expressions. If that trust is broken, then comparisons using True
may not work. Including "if True:".

This is so basic and simple, that you take it for granted. And so do
many others.

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.

[color=blue][color=green]
>> 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[/color]
>True[color=green]
>> = 3, and False = -5, and they change the language so that any[/color]
>boolean[color=green]
>> comparisons return 3 and -5 respectively, my use of True and False
>> will still work.[/color]
>
>This strikes me as comparable to worrying about being killed by an
>asteroid. Is there some actual historical event that makes it more
>plausible to you?[/color]

Again, it was an example of a concept. I was trying to point out
even if the underlying values that the operating system uses to
represent true and false are changed, having True as a constant equal
to a boolean true evaluation, will still work. I chose numbers that
are very unlikely to try demonstrate in an obvious way that the
concept is valid. Sorry, if I lost you.

Does making 'True' and 'False' constants and/or literals have any draw
backs for you? I can only think of benefits and don't see any reason
for not doing it in this particular case. While I admit that any
knowledgable programmer can write good programs without these being
constants or literals, I also realize that python is becoming
popular as a teaching tool for entry level programming. So yes, I
believe errors using and miss using True and False will happen.

<clipped, and opinion noted>

[color=blue]
>
>...[color=green]
>> 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.[/color]
>
>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.
>[/color]

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

Or as someone has stated to me earlier... it is a test that something
does exist. That something being whatever the value x represents.

x is the number of coins I have. ' if x:' is a true statement if I
have some coins. We are testing for the existence of my coins.

[color=blue][color=green]
>> If python had an exists operator, you could do.[/color]
>
>I think you are confusing names and objects. You can only apply an
>operator to objects and only to objects that exist.
>[/color]

No, I'm not confused, and yes I am diverging here.
[color=blue][color=green]
>> if x exists:
>> 'do something'[/color]
>
>Do you mean
>if bound_to_someth ing('x'): <do something>
>?
>[/color]

Yes, you understand.
[color=blue]
>Normally, in the absence of error, one only uses names that one has
>defined (bound to somethingj). So you must be worried about the
>following scenario:
>
>if a: x=1
><more code>
>if exists(x): <do something with x>
>
>In non-module script only:
>import __main__ as mm
>x = 1
>hasattr(mm, 'x') # True
>hasattr(mm, 'y') # False
>
>Anywhere: use try ... except NameError
>
>Or, don't do that (have conditionally defined name). Instead,
>
>x=None
>if a: x = something_not_N one()
><more code>
>if x != None: <do something with x>
>
>In other words, name != None is often idiom for exists('name')!
>[color=green]
>> This could serve two options also... does the object exist?[/color]
>
>Again, Python only operates on objects that do exist.
>[/color]

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.

Being able to check if an object already exists could be useful. I'll
look into the hasattr() function more, thanks for pointing it out.

I did stray a bit on this and I admitted so in my post.


_Ronald Adam

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 23:40:52 -0500, "Terry Reedy" <tjreedy@udel.e du>
wrote:
[color=blue]
>
>"Ron Adam" <radam2@tampaba y.rr.com> wrote in message
>news:8qhirvgi2 sf5l3vkfocq65mc b94c6pbb9s@4ax. com...[color=green]
>> 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.[/color]
>
>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.[/color]

That would be good.

[color=blue][color=green]
>> Their actual internal
>> values shouldn't be relevant or depended on.[/color]
>
>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.[/color]

Good also.
[color=blue][color=green]
>> In python you can change the value of True, or set True to point to
>> something different.[/color]
>
>Yes, you are currently allowed to stab yourself in the back (but even
>this will probably change in the future). Don't do it.
>[/color]
I agree, it's good that it may change.
[color=blue][color=green]
>> For example you can do this.[color=darkred]
>> >>> True = False[/color]
>> Now all bets are off....[/color]
>
>Ditto.
>[color=green]
>> To be sure that True is True and False is
>> False, we need to put in explicit definitions into our programs.[/color]
>
>In 2.2.2+, you only need to not change them and to not work with a
>psycopath.[/color]

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.
[color=blue]
>...[color=green]
>> The above is much less implausible. Do you agree?[/color]
>
>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
>[/color]

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

_Ronald Adam

[Ben Finney]

Re: True inconsistency in Python

On Tue, 18 Nov 2003 07:15:01 GMT, Ron Adam wrote:[color=blue]
> 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.[/color]

Possibly so. For myself, I think it's good that they exist at all now.
Incremental improvement toward a canonical Boolean type is good.

- We now have a separate 'bool' type.
- We now hove True and False singleton objects of type 'bool'.
- Boolean expressions now evaluate to one of these two objects.

These are all quite recent in Python. Perhaps immutable Boolean values
will be in a future Python version. However, I don't see that it's a
pressing need.

Assigning a new value to None is possible (until recently, it didn't
even generate a warning). How much Python code does this break? How
many potential errors does it cause? My guess would be few. Same for
the True and False values (and the numbers, if they were mutable).

There are many ways to shoot yourself in the foot in Python, if you try
hard enough. This is one of them. Acknowledge its existence,
acknowledge that you'd be crazy to do it, and move on.

--
\ "Yesterday I parked my car in a tow-away zone. When I came back |
`\ the entire area was missing." -- Steven Wright |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 18:47:34 -0800, Erik Max Francis <max@alcyone.co m>
wrote:
[color=blue]
>Ron Adam wrote:
>[color=green]
>> I'm not arguing at all. Only exploring the issue.[/color]
>
>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.
>[/color]

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.

[color=blue]
>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.[/color]

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

[color=blue][color=green]
>> So maybe you are correct, we shouldn't use anything. (?)[/color]
>
>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.[/color]

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.

[color=blue]
>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).[/color]

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.

[color=blue]
>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.[/color]

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

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

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.
[color=blue][color=green]
>> 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.[/color]
>
>All the other "preinitial ized variables" have exactly the same
>characteristic . There are no constants in Python.[/color]

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?


[color=blue]
>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.[/color]

It was an observation, not an objection.

[color=blue]
>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.[/color]

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.

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

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

[color=blue][color=green]
>> 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.[/color]
>
>You've gotten severely sidetracked on this thread. The original
>inconsistenc y 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.[/color]

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.

[color=blue][color=green]
>> Doing this causes an error:
>>[color=darkred]
>> >>> 1 = 2[/color]
>> SyntaxError: can't assign to literal
>>
>> Doing this does not cause an error:
>>[color=darkred]
>> >>> True = False
>> >>>[/color][/color]
>
>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.[/color]

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

[color=blue]
>[color=green]
>> Are True and False Bools?[/color]
>
>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,
>thisIsAVariabl e, int, str, sys, etc.
>[color=green]
>> Why are they not also literals? Wouldn't that be consistent?[/color]
>
>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.[/color]

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]

Re: True inconsistency in Python

Ron Adam wrote:
[color=blue]
> 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.[/color]

But True and False are no different from None, int, str, or any of the
other builtins.
[color=blue]
> 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().[/color]

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
"accidental ly" rebinding True or False.
[color=blue]
> 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.[/color]

Yes. And builtins other than True and False are far more frequently
accidentally rebound.
[color=blue]
> 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(),[/color]

It's not true for int, either.
[color=blue]
> 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.[/color]

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 && max@alcyone.com && 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]

Re: True inconsistency in Python


"KefX" <keflimarcusx@a ol.comNOSPAM> wrote in message
news:2003111720 1113.28795.0000 0484@mb-m17.aol.com...[color=blue][color=green]
> >not. However long the expression is, I don't see how adding `==[/color][/color]
true'[color=blue][color=green]
> >at the end makes it more clear.[/color]
>
> What if the expression is 37 lines long?[/color]

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]

Re: True inconsistency in Python


"Ron Adam" <radam2@tampaba y.rr.com> wrote in message
news:83bjrvcm92 o6l2gte1nbehrpv ofm0r5i88@4ax.c om...
[color=blue]
> I believe the words 'True' and 'False' need to be treated the same[/color]
as[color=blue]
> the digits 1, 2, 3, ... The values of the digits do not change.[/color]
We[color=blue]
> 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.[/color]

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.
[color=blue][color=green][color=darkred]
> >> It looks to me that 'True' in python is a combination of the[/color][/color][/color]
boolean[color=blue][color=green][color=darkred]
> >> binary logic of 1 or 0, and as an "exists" test of 0 or not 0.[/color][/color][/color]
[me][color=blue][color=green]
> >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.[/color][/color]
[color=blue]
> if x: is a test to see if the value 0 does not exist in x.[/color]

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.
[color=blue][color=green][color=darkred]
> >> if x exists:
> >> 'do something'[/color]
> >
> >Do you mean
> >if bound_to_someth ing('x'): <do something>
> >?
> >[/color]
>
> Yes, you understand.[/color]

Whoops, now you are agreeing with 'exist' as 'binding existence'.
Yes, this is a 'divergence' from your other sense of exist.
[color=blue]
> 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,[/color]
but[color=blue]
> do not want to re initialize it if it's already been defined.[/color]

For just one variable, I might use

try: x
except NameError: x = 'value'

Terry J. Reedy