True inconsistency in Python

[Erik Max Francis]

Tim Roberts wrote:

> 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 )
>   {
>   }

I think you're getting burned by something else, there :-).

> Visual Basic has exactly the same problem.

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.

> Further, until very
> recently,
> True in VB actually evaulated to -1, so even comparing to "1" would
> fail.

That's because in traditional BASIC, "true" is all-bits on.  The true
constant wasn't 1 in the first place.

> >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
> 
> Your statement is absolutely true.  End of story.

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 at alcyone.com && http://www.alcyone.com/max/
 __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/  \ 
\__/ So little time, so little to do.
    -- Oscar Levant