0 == False but [] != False?

[Rajarshi]

This is a slightly naive question, but I know that 0 can be used to
represent False. So
True

But, I know I can use [] to represent False as in

if not []: print 'empty'

....
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

Thanks,
Rajarshi

 

[Robert Kern]

This is a slightly naive question, but I know that 0 can be used to
represent False. So
True

But, I know I can use [] to represent False as in

if not []: print 'empty'

...
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

"if foo:" does not check if "foo == True" or "foo == False" but rather
"bool(foo)". For empty lists, strings, tuples, dicts and some other things,
"bool(foo) == False", while for lists, etc., with at least one element,
"bool(foo) == True".

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[James Stroud]

This is a slightly naive question, but I know that 0 can be used to
represent False. So


True

But, I know I can use [] to represent False as in

if not []: print 'empty'

...
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

Thanks,
Rajarshi

Meditate on:

py> isinstance(False, int)
True
py> isinstance([], int)
False
py> bool([])
False

James

 

[Raymond Hettinger]

[] == False

False

Could anybody point out why this is the case?

Writing, "if x" is short for writing "if bool(x)".
Evaluating bool(x) checks for a x.__nonzero__()
and if that method isn't defined, it checks for
x.__len__() to see if x is a non-empty container.

In your case, writing "if []" translates to
"if len([]) != 0", which evaluates to False.

True and False are of type bool which is a subclass
of int. So, False really is equal to zero and
True really is equal to one.

In contrast, the empty list is not of type int.
So [] != False eventhough bool([]) == False.


Raymond

 

[Paul McGuire]

This is a slightly naive question, but I know that 0 can be used to
represent False. So

True

But, I know I can use [] to represent False as in

if not []: print 'empty'

...
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

Thanks,
Rajarshi

This has *got* to rank up there among the VFAQ's of them all, along
with the mysterious shared default empty list argument. I think this
particular question has been asked in one form or another at least
twice a week for the past month!

-- Paul

 

[Erik Max Francis]

This is a slightly naive question, but I know that 0 can be used to
represent False. So
True

But, I know I can use [] to represent False as in

if not []: print 'empty'

...
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

Because "representing False" (i.e., being false) and "being the same as
False" are not the same thing.

if x:
...

is not the same thing as

if x == True:
...

it's the same as

if bool(x):
...

So a more meaningful comparison of your two tests are:

>>> bool(0) == bool(False) True
>>> bool([]) == bool(False)

True

 

[Tim Roberts]

This is a slightly naive question, but I know that 0 can be used to
represent False. So
True

But, I know I can use [] to represent False as in

if not []: print 'empty'

...
empty

But then doing the following gives a surprising (to me!) result

[] == False

False

Could anybody point out why this is the case?

False is just a constant. 0, (), '', [], and False are all constants that
happen to evaluate to a false value in a Boolean context, but they are not
all the same.

As a general rule, I've found code like "if x == False" to be a bad idea in
ANY language.

 

[Steven D'Aprano]

As a general rule, I've found code like "if x == False" to be a bad idea in
ANY language.

Surely that should be written as "if (x == False) == True"?

 

[Rex Turnbull]

Steven D'Aprano :

Surely that should be written as "if (x == False) == True"?

Why compare to False?

" if not x : ... "

It really doesn't matter if x is False or if it evaluates to False. Many
things evaluate to False like [], (), 0, "", None and a few other things.


.... if thing : print "True thing", thing
.... elif not thing : print "False thing",thing
.... else : print "No thing"
....

>>> tf([]) False thing []
>>> tf([1]) True thing [1]
>>> a = ()
>>> tf(a) False thing ()
>>> a=(0)
>>> tf(a) False thing 0
>>> a= (1,2,3)
>>> tf(a) True thing (1, 2, 3)
>>> tf("abc") True thing abc
>>> tf("") False thing
>>>

 

[Grant Edwards]

Steven D'Aprano :

Why compare to False?

That's a joke... I say, that's a joke, son!

He was being sarcastic.

 

[Donn Cave]

This has *got* to rank up there among the VFAQ's of them all, along
with the mysterious shared default empty list argument. I think this
particular question has been asked in one form or another at least
twice a week for the past month!

Anyone who finds this surprising, might enjoy reading this
article from the time several years ago when the feature
was being considered. When you have some time - it's long,
but interesting. The present confusion is more directly
addressed towards the end. Yes, it's the Laura Creighton
article again:

http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360

Donn Cave, (e-mail address removed)

 

[Erik Max Francis]

Anyone who finds this surprising, might enjoy reading this
article from the time several years ago when the feature
was being considered. When you have some time - it's long,
but interesting. The present confusion is more directly
addressed towards the end. Yes, it's the Laura Creighton
article again:

http://groups.google.com/group/comp.lang.python/msg/2de5e1c8384c0360

If so, be sure to click "More options," then "View thread," and then
read the responses. There were many reasonable objections to her points.

 

[Dan Bishop]

False is just a constant. 0, (), '', [], and False are all constants that
happen to evaluate to a false value in a Boolean context, but they are not
all the same.

As a general rule, I've found code like "if x == False" to be a bad idea in
ANY language.

I have a job as a C++ programmer, and they make us write it like that,
apparently because the ! operator is hard to see. But "if (x ==
TRUE)" is discouraged.

 

[Steve Holden]

False is just a constant. 0, (), '', [], and False are all constants that
happen to evaluate to a false value in a Boolean context, but they are not
all the same.

As a general rule, I've found code like "if x == False" to be a bad idea in
ANY language.

I have a job as a C++ programmer, and they make us write it like that,
apparently because the ! operator is hard to see. But "if (x ==
TRUE)" is discouraged.

Find a new employer. I'm not joking.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

 

[Erik Max Francis]

Find a new employer. I'm not joking.

Really. He's not. That's a perfect example of a style guideline that
not only wastes energy, misses the point, but is totally wrong.

 

[Rajarshi]

Thanks a lot for all the responses

 

[Donn Cave]

If so, be sure to click "More options," then "View thread," and then
read the responses. There were many reasonable objections to her points.

Not that it is of no historical interest to review all these
reasonable arguments, but allow me to restore the context quote
from my follow-up:

This has *got* to rank up there among the VFAQ's of them all, along
with the mysterious shared default empty list argument. I think this
particular question has been asked in one form or another at least
twice a week for the past month!

Donn Cave, (e-mail address removed)

 

[Erik Max Francis]

Not that it is of no historical interest to review all these
reasonable arguments, but allow me to restore the context quote
from my follow-up:

If the counterpoints are of no historical interest, then the original
point must be of no historical interest either, since it was not widely
granted as true.

 

[Donn Cave]

If the counterpoints are of no historical interest, then the original
point must be of no historical interest either, since it was not widely
granted as true.

"Not that it is of no historical interest" may have been too
hard to follow, my apologies. I should have said "It may be of
historical interest ...". After that, you lost me, but I guess
I'm not going to worry about it.

Donn Cave, (e-mail address removed)

 

[Steven D'Aprano]

If the counterpoints are of no historical interest, then the original
point must be of no historical interest either, since it was not widely
granted as true.

I hope you don't get just as confused by expressions like:

if not x != 5

*wink*

In English, a double negative is usually a positive. So "Not that it is of
no historical interest" means "It is of historical interest".

I wonder, if somebody with more time on their hands than me were to go
through the threads on comp.lang.python before and after the introduction
of bools, could we determine whether there were more problems caused by
the introduction of True and False than by the lack of them? Although I
like using bools, in my heart of hearts I suspect that Laura was right.