and [True,True] --> [True, True]?????

[Steven D'Aprano]

On Mon, 20 Apr 2009 15:53:41 +0000, Peter Pearson wrote:

> Like Gerhard, I prefer the construction that explicitly says, "This is a
> list, and this is what I'll do if it's not empty."  To me, and I suspect
> to a great many programmers, "if x:" does *not* mean "if x is not
> empty", it means "if x is (in some sense) True, including the
> possibility that x is an object from which a True or False value must be
> extracted by means that might not be at all obvious."

That's *exactly* what it means. This is a feature, not a bug.

No matter what x is (excluding buggy classes), "if x" means "test whether 
x is true in a boolean context".

If x happens to be a list, that means "x is empty". If x is a float, it 
means "x is positive or negative zero". If x is a phlange, it means the 
doofer is unset or it has more than three frobs.

You shouldn't care exactly why x is true or false, only that it is. Why 
should you have to manually count the frobs when the class can do it for 
you?



> For an object
> lesson in the perils of said extraction, see the recent thread on
> [False,True] and [True,True] == [True,True].

That would be this thread :)

The OP's problem was not with boolean contexts, but with the mistaken 
idea that the "and" operator does element by element comparison.

Pop quiz: what's the difference between:

if [False, False]:
    print "something"

and

if len([False, False]) != 0:
    print "something"

?



-- 
Steven