True inconsistency in Python

[Erik Max Francis]

Re: True inconsistency in Python

Borcis wrote:
[color=blue]
> there's the equivalent, and more explicit :
>
> if bool(var)==True : blah[/color]

The explicitness here does not gain you anything. In a truth context,
x, bool(x), and bool(x) == True are all precisely identical. There is
absolutely no value gained by writing bool(x) == True instead of just x.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ The golden rule is that there are no golden rules. -- George
Bernard Shaw

[Ron Adam]

Re: True inconsistency in Python

On Thu, 13 Nov 2003 00:19:31 -0800, "Michael Geary"
<Mike@DeleteThi s.Geary.com> wrote:
[color=blue]
>Ron Adam:[color=green]
>> The only thing that surprises me in all of this is the
>> "if var:" evaluating to true for numbers other than 1.
>> That's new to me, I would have expected an
>> exception in that case. But it still makes since if I
>> look at it as a shortcut for "if (var != 0):". This only
>> proves I'm still relatively new to Python I think.[/color]
>
>It's handy, and natural in many real life situations, to treat any nonzero
>value as "true". For example:
>
>Do you have any money in your wallet?
>
>Do you have children?
>
>I could ask how much money or how many children you have, but if I just ask
>the yes-or-no question, you'll naturally answer "yes" for any nonzero value.
>
>Of course, if you have children, you won't have money, but that's a separate
>problem...
>
>-Mike
>[/color]

That makes since, Thanks for clarifying this.

I learned boolean logic as part of a computer tech degree back in
early 80's. Binary logic circuits use only 0 and 1. So it's the way
I think when dealing with bool type.

_Ron Adam

[Michele Simionato]

Re: True inconsistency in Python

Gerrit Holl <gerrit@nl.linu x.org> wrote in message news:<mailman.7 26.1068754624.7 02.python-list@python.org >...[color=blue]
>
> (btw, I _do_ use bool ocasionally: I implemented an anytrue() function
> using sum([bool(i) for i in L]), is this wrong?)
>
> Gerrit.
>
> --
> 128. If a man take a woman to wife, but have no intercourse with her,
> this woman is no wife to him.
> -- 1780 BC, Hammurabi, Code of Law[/color]

It does not shortcut, i.e. it creates the full list. For the rest, it
is a matter of personal opinion if this idea is considered cool or
an abuse of sum. I personally, will propend for the latter, but since
we don't have yet an anytrue function in the library, for the moment it
can be tolered). Just my 0.02 E.

Michele

[Terry Reedy]

Re: True inconsistency in Python


"Ben Finney" <bignose-hates-spam@and-benfinney-does-too.id.au> wrote
in message news:slrnbr69ml .ge6.bignose-hates-spam@iris.polar .local...[color=blue]
> This conflation of types is confusing,[/color]

but very useful
[color=blue]
>and (like many other languages)
> Python has now "grown a Boolean type" to distinguish integer 0 and 1
> from Boolean False and True. However, the previous behaviour is[/color]
still[color=blue]
> supported -- for how long, I don't know.[/color]

When bool was introduced, Guido promised that is would always remain a
subtype of int. Crippling usefulness in the name of mathematical
purity is not on the table.

Terry J. Reedy

[Terry Reedy]

Re: True inconsistency in Python


"Scott Chapman" <scott_list@mis chko.com> wrote in message
news:mailman.69 4.1068696749.70 2.python-list@python.org ...[color=blue]
> There seems to be an inconsistency here:[/color]

In regard to logic, the current Python implementation acts just as
specified in the manaul, which is written as intended. This is the
only consistency relevant to Python.

In math, an inconsistent set of premises is one from which one can
derive both true and false. Python as delivered has no such
inconsistency in that sense either. bool(object) is either True or
False for every Python object except possibly for instances of a user
class with the appropriate special method mangled either by accident
or perverse intention.

In static math, x = x+1 is read as x == x+1, which is usually false.
But programming is not mathematics.

If you merely meant "Python is not consistent with my expectations"
then I suppose you are right. If that really bothers you, I suspect
you know the realistic remedy ;-).

Terry J. Reedy

[Alex Martelli]

Re: True inconsistency in Python

Gerrit Holl wrote:
[color=blue]
> Alex Martelli wrote:
> (about x vs. bool(x))[color=green]
>> [[ we TOLD Guido people would start on this absurd path, when
>> he added bool, True, and False, but he wouldn't listen...
>> ]][/color]
>
> What do double square brackets mean?[/color]

"Inline footnote" or the like;-). I do like to pep up my posts
despite the limitations of plain ascii...

[color=blue]
> (btw, I _do_ use bool ocasionally: I implemented an anytrue() function
> using sum([bool(i) for i in L]), is this wrong?)[/color]

Not wrong, just potentially a bit slow for very large L's, but for
your applications you may not care. Compare:


[alex@lancelot tmp]$ timeit.py -c -s'xs=[0]*999' -s'[color=blue]
> def anytrue_sc(L):
> for i in L:
> if i: return True
> else:
> return False
> def anytrue_ns(L):
> return sum([ bool(i) for i in L ])
> ' 'anytrue_sc(xs) '[/color]
1000 loops, best of 3: 200 usec per loop

and the same with 'anytrue_ns(xs) ' instead,

1000 loops, best of 3: 1.26e+03 usec per loop

while, also, with 'anytrue_sc([1]+xs]':

10000 loops, best of 3: 22 usec per loop

while with 'anytrue_ns([1]+xs]':

1000 loops, best of 3: 1.29e+03 usec per loop


So, on a 1000-long list, you may be slowing things down by 6 to
60 times, depending on where (if anywhere) the first true item
of L might be, by using the "clever" bool rather than the plain
good old loop-with-shortcircuit.

Now, for some people "one-liners" (which you could write the _ns
version as; the _sc version can't be less than 4 lines) are much
more important than speed or elementary-clarity. For those
people, I suggest an approach that's only a BIT slower than the
simplest and most obvious one:

[alex@lancelot tmp]$ timeit.py -c -s'xs=[0]*999' -s'import itertools as it[color=blue]
> import operator
> def anytrue_it(L):
> return list(it.islice( it.dropwhile(op erator.not_, L),1))
> ' 'anytrue_it(xs) '[/color]
1000 loops, best of 3: 310 usec per loop

and with 'anytrue_it([1]+xs)', 28 usec per loop. Now, you have
bounded your performance loss to 30-50% when compared to the simplest
approach, and one can of course pull out all the stops...:

[alex@lancelot tmp]$ timeit.py -c -s'xs=[0]*999' -s'import itertools as it
import operator
def anytrue_it(L, slice=it.islice , drop=it.dropwhi le, not_=operator.n ot_):
return list(slice(drop (not_, L),1))
' 'anytrue_it(xs) '
1000 loops, best of 3: 270 usec per loop

to reach a 35%-or-so max loss of performance in this case.

Plus, it's much cooler for the purpose of making your friends' heads
spin with admiration for your wizardry, of course;-).


Alex

[Tim Roberts]

Re: True inconsistency in Python

Scott Chapman <scott_list@mis chko.com> wrote:[color=blue]
>
>Historically Python has allowed <> 0 to equal true in evaluations. Now
><> 0 still evaluates to true in evaluations. However it doesn't equal
>True. They are not interchangable. (Same with empty lists, etc.)[/color]

Python is certainly not the only language in which this occurs. Many are
the C programmers who have been burned by:

int SomeFunction();
...
if( SomeFunction == TRUE )
{
}

Visual Basic has exactly the same problem. Further, until very recently,
True in VB actually evaulated to -1, so even comparing to "1" would fail.

This should not be a surprise. Booleans should be thought of as enumerated
integral types.
[color=blue]
>Assuming the old behavior is desired, programmers need to be careful
>not to compare a variable with True as in:
>
>if var == True: # only works if var is 1
> blah[/color]

Your statement is absolutely true. End of story.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[Erik Max Francis]

Re: True inconsistency in Python

Tim Roberts wrote:
[color=blue]
> Python is certainly not the only language in which this occurs. Many
> are
> the C programmers who have been burned by:
>
> int SomeFunction();
> ...
> if( SomeFunction == TRUE )
> {
> }[/color]

I think you're getting burned by something else, there :-).
[color=blue]
> Visual Basic has exactly the same problem.[/color]

It's not a problem, explicitly comparison with a Boolean literal,
whether or not Booleans are not distinct types (Lisp, C89), are distinct
types with implicit conversion (C++, Python), or are distinct types in
which implicit conversions are disallowed (Java) is completely
superfluous. The proper way to test whether an expression is true is

if (expression)
...

What is the point of the explicit test with the true constant? What
about the result of _that_ comparison, shouldn't that be tested with
true as well -- ((expression == TRUE) == TRUE)? But what about _that_
result, shouldn't it be tested too?

Explicit comparison with the true constant (or false constant)
necessarily degenerates into complete uselessness.
[color=blue]
> Further, until very
> recently,
> True in VB actually evaulated to -1, so even comparing to "1" would
> fail.[/color]

That's because in traditional BASIC, "true" is all-bits on. The true
constant wasn't 1 in the first place.
[color=blue][color=green]
> >Assuming the old behavior is desired, programmers need to be careful
> >not to compare a variable with True as in:
> >
> >if var == True: # only works if var is 1
> > blah[/color]
>
> Your statement is absolutely true. End of story.[/color]

It's true in that that might cause a problem, but it's not true that
that's undesirable language behavior. It's programmer error -- in any
language that has a Boolean true (or false) literal.

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

[KefX]

Re: True inconsistency in Python

>Explicit comparison with the true constant (or false constant)[color=blue]
>necessarily degenerates into complete uselessness.[/color]

(For those just joining us, this statement was made about all languages, not
just Python.)

I'm not so sure about that. In most languages (including Python), 'false' is
guaranteed to be only one value (usually zero), therefore comparing against it
poses no problem. I assume you're saying that doing so isn't problematic in any
way, it's just pointless.

Well, actually, some coding standards suggest you always compare against false.
This is so the code is slightly more clear, and "!= false" avoids the pitfall
that "== true" has. The problem of course is that some unwitting maintenance
programmer may decide that "== true" os more clear than "!= false", not
realizing it is wrong...which is why all maintenance programmers should read
programming standards. :) We can't program in baby C just for them, after all,
but we shouldn't make things unnecessarily difficult for them either, but I
think we have bigger things to worry about if a maintenance programmer fails to
understand such a simple concept after being told about it.

Now of course any idiot C (or C++, or Java) programmer knows that these two are
equivalent:

if(blah != false)
do_blah();

if(blah)
do_blah();

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". This is especially valuable in really
long 'if' statements, such as one might want for an inverse parser (don't worry
if you don't know what one is). The idea is if you compare against 'false' all
the time, you won't forget it when it would actually give the code more
clarity.

One standard which suggests this is the one Steve Maguire proposes in the book
Writing Solid Code. This is probably the best book on C coding guidelines that
I've ever read, despite it being written by a Microsoft programmer. ;) Although
much of it is specific to C, a lot of the concepts apply to other languages,
including Python.

However, comparing against a boolean is discouraged in Python (but your
argument wasn't about Python specifically), so I wouldn't do it in Python: when
in Rome, do as the Romans do. Although, as a last thought, it should be
relatively easy to make it so that True returns '1' in any comparison except
against 0. A class would be able to do this easily by overriding __cmp__:

def true_class(bool ):
def __cmp__(self, other):
if other:
return 1
else:
return 0

True = true_class()

(of course this class definition would be tweaked to make it a singleton)
I'm assuming there's a good reason for not doing it this way (or in an
equivalent fashion), though...what else might we add to this discussion?

- Kef

[Dennis Lee Bieber]

Re: True inconsistency in Python

Tim Roberts fed this fish to the penguins on Sunday 16 November 2003
23:58 pm:
[color=blue]
>
> Visual Basic has exactly the same problem. Further, until very
> recently, True in VB actually evaulated to -1, so even comparing to
> "1" would fail.
>
> This should not be a surprise. Booleans should be thought of as
> enumerated integral types.
>[/color]
Then there is VMS, in which odd return codes would evaluate to true
and even return codes to false (odd codes being "info"/"success", even
codes being "error"/"warning"). ie; 1, 3, 5, ... are "true"; 0, 2, 4
.... are "false".

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 00:19:11 -0800, Erik Max Francis <max@alcyone.co m>
wrote:
[color=blue]
>Tim Roberts wrote:
>[color=green]
>> Python is certainly not the only language in which this occurs. Many
>> are
>> the C programmers who have been burned by:
>>
>> int SomeFunction();
>> ...
>> if( SomeFunction == TRUE )
>> {
>> }[/color]
>
>I think you're getting burned by something else, there :-).
>[color=green]
>> Visual Basic has exactly the same problem.[/color]
>
>It's not a problem, explicitly comparison with a Boolean literal,
>whether or not Booleans are not distinct types (Lisp, C89), are distinct
>types with implicit conversion (C++, Python), or are distinct types in
>which implicit conversions are disallowed (Java) is completely
>superfluous. The proper way to test whether an expression is true is
>
> if (expression)
> ...[/color]


To me the usefulness of using True and False is that it is defined to
values consistent with the programming language that you are using.
So using them to assign x = True, or x = False. insures that when I
do:

x = True
if x:
....

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 True
= 3, and False = -5, and they change the language so that any boolean
comparisons return 3 and -5 respectively, my use of True and False
will still work. If I tested for 1 or 0 using the 'if x:' method,
then my program will break.

x = 1
if x: # returned value undefined, x is not 3 or -5

So I do an explicit test 'if (x=1)' to make sure it will work even if
'True' gets redefined.

So we should either use explicit comparisons of values, or use only
True and False, but not mix them.

[color=blue]
>
>What is the point of the explicit test with the true constant? What
>about the result of _that_ comparison, shouldn't that be tested with
>true as well -- ((expression == TRUE) == TRUE)? But what about _that_
>result, shouldn't it be tested too?
>
>Explicit comparison with the true constant (or false constant)
>necessarily degenerates into complete uselessness.
>[color=green]
>> Further, until very
>> recently,
>> True in VB actually evaulated to -1, so even comparing to "1" would
>> fail.[/color]
>
>That's because in traditional BASIC, "true" is all-bits on. The true
>constant wasn't 1 in the first place.
>[color=green][color=darkred]
>> >Assuming the old behavior is desired, programmers need to be careful
>> >not to compare a variable with True as in:
>> >
>> >if var == True: # only works if var is 1
>> > blah[/color]
>>
>> Your statement is absolutely true. End of story.[/color]
>
>It's true in that that might cause a problem, but it's not true that
>that's undesirable language behavior. It's programmer error -- in any
>language that has a Boolean true (or false) literal.[/color]


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.

If python had an exists operator, you could do.

if x exists:
'do something'

This could serve two options also... does the object exist? or does
a value exist where the value is not equal to zero or None. There
would need to be a syntax difference between the two.

Using the 'if x:' form does this for values and is clear enough. So
using an 'exists()' function to check for the presence of an object
would be useful if there isn't a simple way to do it already. Right
now it you do this without first assigning a value to x you get:
[color=blue][color=green][color=darkred]
>>> if x:[/color][/color][/color]
pass


Traceback (most recent call last):
File "<pyshell#2 >", line 1, in -toplevel-
if x:
NameError: name 'x' is not defined[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

There is an os.path.exists( ) function for checking if a file path
exists. A more general exists() function or method my be useful and
still be consistent with it.

With pythons dynamic variables, I think an exists function would be
useful to check if an object exists. And to use 'if x:' to check if
a (value!=0) exists. It's clear what is being tested for from the
context.

I can't do:

def exists(object):
try object:
return True
return False

if not exists(object):
object = 0


This generates a not defined error if object isn't defined when exists
is called.


So I have to do:


try:
if object:
exist = True
except:
exist = False
if not exist:
object = 0

That can be shortened to:

try:
if object:
pass
except:
object = 0

This isn't to bad, but I would prefer something like,

if not object.exists: # does the abject already exist?
object = 0 # if not, create and set initial value
# else use the existing value

I think I diverged from True or False a bit here. And I'm not sure if
this functionality already exists or not?

_Ron Adam



























There's probably a way to do this in python already.

[Michael Geary]

Re: True inconsistency in Python

KefX:[color=blue]
> Well, actually, some coding standards suggest you always compare against[/color]
false.[color=blue]
> This is so the code is slightly more clear, and "!= false" avoids the[/color]
pitfall[color=blue]
> that "== true" has. The problem of course is that some unwitting[/color]
maintenance[color=blue]
> programmer may decide that "== true" os more clear than "!= false", not
> realizing it is wrong...which is why all maintenance programmers should[/color]
read[color=blue]
> programming standards. :) We can't program in baby C just for them, after[/color]
all,[color=blue]
> but we shouldn't make things unnecessarily difficult for them either, but[/color]
I[color=blue]
> think we have bigger things to worry about if a maintenance programmer[/color]
fails to[color=blue]
> understand such a simple concept after being told about it.
>
> Now of course any idiot C (or C++, or Java) programmer knows that these[/color]
two are[color=blue]
> equivalent:
>
> if(blah != false)
> do_blah();
>
> if(blah)
> do_blah();
>
> 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,[/color]
whereas[color=blue]
> 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". This is especially valuable in[/color]
really[color=blue]
> long 'if' statements, such as one might want for an inverse parser (don't[/color]
worry[color=blue]
> if you don't know what one is). The idea is if you compare against 'false'[/color]
all[color=blue]
> the time, you won't forget it when it would actually give the code more
> clarity.[/color]

That strikes me as a really bad practice, in C, Python, or any language with
a similar if statement. Code should read the way people think, and people
don't tack on "!= false" when they make decisions based on conditions.

Which would you say: "If you're hungry, eat!" or "If your hunger is not
equal to false, eat!"

So which is more clear:

if( hungry )
eat();

or:

if( hungry != false )
eat();

It's just as bad when you want to make the opposite test. Do you say, "If
you're not hungry, don't eat!" or "If your hunger is equal to false, don't
eat!"

So do you code:

if( ! hungry )
dontEat();

or:

if( hungry == false )
dontEat();

(For those not familiar with C, "!" is the logical not operator and is
pronounced "not".)

I don't buy the argument that "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.'" You *always* have to
look at the whole thing, and an if statement always tests its entire
argument for truth or falsity. Adding an explicit "!= false" or "== false"
simply adds noise and reduces clarity.

Comparing against a boolean isn't discouraged in Python because of some
arbitrary cultural preference, it's discouraged because it makes code harder
to read and understand.

-Mike

[Erik Max Francis]

Re: True inconsistency in Python

KefX wrote:
[color=blue]
> I'm not so sure about that. In most languages (including Python),
> 'false' is
> guaranteed to be only one value (usually zero), therefore comparing
> against it
> poses no problem. I assume you're saying that doing so isn't
> problematic in any
> way, it's just pointless.[/color]

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=blue]
> Well, actually, some coding standards suggest you always compare
> against false.[/color]

My point is that any such coding standard is dumb.
[color=blue]
> 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. It's a Boolean test, what's to make
explicit?

All including the explicit test there does is make other programmers
wonder if you've lost your mind, and admit the possibility of you making
the type of error we've been discussing (x == True) where True is a
solitary constant in a much larger world of Booleans which evaluate as
true. 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.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ Why don't you grow up for crying out loud?
-- Capt. Benjamin "Hawkeye" Pierce

[Erik Max Francis]

Re: True inconsistency in Python

Ron Adam wrote:
[color=blue]
> To me the usefulness of using True and False is that it is defined to
> values consistent with the programming language that you are using.[/color]

I agree, insofar as the value of True and False as constants is that now
have values set aside which mean _nothing_ but their Boolean values.
This is very helpful for writing self-documenting code, something which
I've always been a strong supporter of. If I have code where 0 or 1
gets assigned to a variable, I'm going to have to look at the whole
block to tell precisely what that's being used for: Is it a counter
variable, a three-state value (say, -1, 0, and +1), is it an enumerated
value type, or is it a Boolean? If I'm scanning code and I see

x = True

then I know right away that what I'm looking at is a variable used as a
Boolean. (Of course, in proper self-documenting code, the variable
would be named something more helpful than `x', but you see my point.)
[color=blue]
> So using them to assign x = True, or x = False. insures that when I
> do:
>
> x = True
> if x:
> ....
>
> 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 True
> = 3, and False = -5, and they change the language so that any boolean
> comparisons return 3 and -5 respectively, my use of True and False
> will still work. If I tested for 1 or 0 using the 'if x:' method,
> then my program will break.[/color]

While this may be true in some sense, I don't think this is a powerful
argument for using True/False. The chances of this happening are
utterly remote, since it would break practically all code. (Obviously
you weren't suggesting it was a real possibility given your choices of
the alternate constants, but still.)

I don't consider insulation from something utterly implausible happening
very persuasive, since I'm not worried about that utterly implausible
thing happening. I find explicit Boolean constants available for
writing self-documenting code much more compelling.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \
\__/ Why don't you grow up for crying out loud?
-- Capt. Benjamin "Hawkeye" Pierce

[Ron Adam]

Re: True inconsistency in Python

On Mon, 17 Nov 2003 11:24:54 -0800, Erik Max Francis <max@alcyone.co m>
wrote:
[color=blue]
>Ron Adam wrote:
>[color=green]
>> To me the usefulness of using True and False is that it is defined to
>> values consistent with the programming language that you are using.[/color]
>
>I agree, insofar as the value of True and False as constants is that now
>have values set aside which mean _nothing_ but their Boolean values.
>This is very helpful for writing self-documenting code, something which
>I've always been a strong supporter of. If I have code where 0 or 1
>gets assigned to a variable, I'm going to have to look at the whole
>block to tell precisely what that's being used for: Is it a counter
>variable, a three-state value (say, -1, 0, and +1), is it an enumerated
>value type, or is it a Boolean? If I'm scanning code and I see
>
> x = True
>
>then I know right away that what I'm looking at is a variable used as a
>Boolean. (Of course, in proper self-documenting code, the variable
>would be named something more helpful than `x', but you see my point.)
>[color=green]
>> So using them to assign x = True, or x = False. insures that when I
>> do:
>>
>> x = True
>> if x:
>> ....
>>
>> 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 True
>> = 3, and False = -5, and they change the language so that any boolean
>> comparisons return 3 and -5 respectively, my use of True and False
>> will still work. If I tested for 1 or 0 using the 'if x:' method,
>> then my program will break.[/color]
>
>While this may be true in some sense, I don't think this is a powerful
>argument for using True/False. The chances of this happening are
>utterly remote, since it would break practically all code. (Obviously
>you weren't suggesting it was a real possibility given your choices of
>the alternate constants, but still.)[/color]

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 python you can change the value of True, or set True to point to
something different.

For example you can do this.
[color=blue][color=green][color=darkred]
>>> True[/color][/color][/color]
True[color=blue][color=green][color=darkred]
>>> False[/color][/color][/color]
False[color=blue][color=green][color=darkred]
>>> True = False
>>> True[/color][/color][/color]
False

Now all bets are off.... To be sure that True is True and False is
False, we need to put in explicit definitions into our programs.
[color=blue][color=green][color=darkred]
>>>True = True
>>>True[/color][/color][/color]
False

Ooops.... <wink> so much for that. So we need to do it this way.
[color=blue][color=green][color=darkred]
>>>True = (1==1)
>>>True[/color][/color][/color]
True


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.

x = True

"lots of code"

True = 3 # as a programming error.

"more code"

if (x == True): # evaluates as False!
print True
else:
print False


or possibly this.....


True = 0 # another programming error

"lost of code"

x = True
if x: # evaluates as False again!
print True
else:
print False

[color=blue]
>
>I don't consider insulation from something utterly implausible happening
>very persuasive, since I'm not worried about that utterly implausible
>thing happening. I find explicit Boolean constants available for
>writing self-documenting code much more compelling.[/color]

The above is much less implausible. Do you agree?


_Ronald Adam