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
--
http://mail.python.org/mailman/listinfo/python-list
