question about True values

[John Salerno]

I'm a little confused. Why doesn't s evaluate to True in the first part,
but it does in the second? Is the first statement something different?

>>s = 'hello'
s == True

False

>>if s:

print 'hi'
hi

>>>

Thanks.

[Fredrik Lundh]

John Salerno wrote:

I'm a little confused. Why doesn't s evaluate to True in the first part,
but it does in the second? Is the first statement something different?

>>s = 'hello'
>>s == True

False

>>if s:

print 'hi'

"true" != "True". comparing a value to another value isn't the same
thing as interpreting a value in a specific context:

http://docs.python.org/lib/truth.html

</F>

[Tim Chase]

I'm a little confused. Why doesn't s evaluate to True in the first part,

but it does in the second? Is the first statement something different?

>>s = 'hello'
>>s == True

False

>>if s:

print 'hi'

The "if s" does an implicit (yeah, I know, "explicit is better
than implicit") conversion to bool, like

if bool(s):

And as such, you'll find that

bool(s) == True

You can learn more at

http://docs.python.org/lib/truth.html

where you'll see that it's not really exactly a bool() call, but
that strings are a special case listed here. And if not, they
also have a __len__ method which would return zero/non-zero in
the even that strings weren't handled, making the "actual" test
(if strings weren't special-cased)

(s.__len__() <0) == True

-tkc

[John Salerno]

John Coleman wrote:

But then why is 3.0 == 3 true? They are different types.

Good question. Does one type get converted to the other automatically?
That's all I can think of...

[Tim Chase]

So I suppose

>
if (10 5)

would be the same as

if (10 5) == True

because (10 5) does evaluate to "True".

Yes...and similarly,

if ((10 5) == True) == True

for the same reason...as does

if (((10 5) == True) == True) == True

as does... :*)

-tkc

[John Coleman]

Paul Rubin wrote:

"John Coleman" <jc******@franc iscan.eduwrites :

then "x == 3" is false, but "int(x) == 3" is true.

But then why is 3.0 == 3 true? They are different types.

The 3 gets converted to float, like when you say

x = 3.1 + 3

the result is 6.1.

Yes - it just seems that there isn't a principled reason for implicitly
converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
boolean in "cat" == true. There is something to be said about SML's
rigourous approach where 3.0 = 3 isn't even allowed since it is
considered ill-typed. Nevertheless, it is doubtlessly convientent to be
able to compare integers and doubles directly in the natural way and
there is little practical reason to compare a string with a truth value
so Python's solution does have common sense on its side.

[Martin v. Löwis]

sk**@pobox.com schrieb:

the string class's "nil" value. Each of the builtin types has such an
"empty" or "nil" value:

string ""
list []
tuple ()
dict {}
int 0
float 0.0
complex 0j
set set()

Any other value besides the above will compare as "not false".

This list of values that are considered false is incomplete,
though. Four obvious omissions are

long 0L
unicode u""
bool False
NoneType None

Not-so-obviously, arbitrary user-defined values can also be
treated as false: If they implement __nonzero__, they are
false if False is returned from __nonzero__; otherwise,
if they implement __len__, they are false if 0 is returned
from __len__. Under these rules, array.array objects can
also be false, as can UserList and UserDict objects.

Regards,
Martin

[Martin v. Löwis]

John Coleman schrieb:

Yes - it just seems that there isn't a principled reason for implicitly
converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
boolean in "cat" == true.

Sure there is: equality should be transitive. So while we have
3 == 3L == 3.0 == 3.0+0j
and can therefore imply that 3 == 3.0+0j, we should not get
5 == True == ["foo"]
and therefore imply that 5 == ["foo"].

The phenomenon really exists only for numeric types (that two
values of different types still represent the same "thing"),
so it's not surprising that this doesn't readily extend to
other types.

In Python, there are only very few similar cases: byte strings
and unicode strings sometimes compare equal (but, since 2.5,
don't compare unequal very often); lists and tuples could be
considered to have equal values, but don't actually do compare
equal.

Regards,
Martin

[John Coleman]

Martin v. Löwis wrote:

John Coleman schrieb:

Yes - it just seems that there isn't a principled reason for implicitly
converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat"to
boolean in "cat" == true.

Sure there is: equality should be transitive. So while we have
3 == 3L == 3.0 == 3.0+0j
and can therefore imply that 3 == 3.0+0j, we should not get
5 == True == ["foo"]
and therefore imply that 5 == ["foo"].

The phenomenon really exists only for numeric types (that two
values of different types still represent the same "thing"),
so it's not surprising that this doesn't readily extend to
other types.

In Python, there are only very few similar cases: byte strings
and unicode strings sometimes compare equal (but, since 2.5,
don't compare unequal very often); lists and tuples could be
considered to have equal values, but don't actually do compare
equal.

Regards,
Martin

Very good point, though one could argue perhaps that when one is
comparing an object with a truth value then one is implicitly asking
for the truth value of that object i.e. how it would function if used
in an if statement, etc. This would make code like 'if s: ' equivalent
to 'if s == True:' with a possible gain in readability. But - as you
demonstrate the cost of that (minimal) gain in readability would be too
high. In any event - I think it is mostly bad style to use a
non-boolean variable in 'if s:' - it reminds me too much of obscure C
code (though others might disagree).

-John Coleman

[George Sakkis]

Martin v. Löwis wrote:

sk**@pobox.com schrieb:

the string class's "nil" value. Each of the builtin types has such an
"empty" or "nil" value:

string ""
list []
tuple ()
dict {}
int 0
float 0.0
complex 0j
set set()

Any other value besides the above will compare as "not false".

This list of values that are considered false is incomplete,
though. Four obvious omissions are

long 0L
unicode u""
bool False
NoneType None

Not-so-obviously, arbitrary user-defined values can also be
treated as false: If they implement __nonzero__, they are
false if False is returned from __nonzero__; otherwise,
if they implement __len__, they are false if 0 is returned
from __len__. Under these rules, array.array objects can
also be false, as can UserList and UserDict objects.

A notable exception are numarray arrays (probably true for numpy too, I
haven't tested it though):

>>from numarray import array
bool(array([1,2]))

Traceback (most recent call last):
File "<stdin>", line 1, in ?
RuntimeError: An array doesn't make sense as a truth value. Use any(a)
or all(a).

George

[Donn Cave]

In article <11************ **********@f16g 2000cwb.googleg roups.com>,
"John Coleman" <jc******@franc iscan.eduwrote:

Very good point, though one could argue perhaps that when one is
comparing an object with a truth value then one is implicitly asking
for the truth value of that object

On the contrary -- since there is normally no need to ever
compare an object with a truth value, then I would interpret
this usage as an attempt to distinguish True or False from
other objects in general. Some kind of placeholders for
missing values, who knows. I'm not saying it's a great idea,
but it could work in recent versions of Python.

This would make code like 'if s: ' equivalent
to 'if s == True:' with a possible gain in readability. But - as you
demonstrate the cost of that (minimal) gain in readability would be too
high. In any event - I think it is mostly bad style to use a
non-boolean variable in 'if s:' - it reminds me too much of obscure C
code (though others might disagree).

Others will indeed disagree. I don't think you'll find
much support for this position. But it's not as bad as
your notion that "if s == True", where s is not a boolean
object, might represent a gain in readability. That really
redefines readability.

Donn Cave, do**@u.washingt on.edu