On 21 Apr 2009 03:06:40 GMT, Steven D'Aprano wrote: > 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?
That whimsical example is surprisingly persuasive for me. >> 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 :) Oh, dear. Indeed, it is exactly this increasing scarcity of at-hand working memory that makes me resist non-obvious features in programming languages. Perhaps it's time to take up golf. -- To email me, substitute nowhere->spamcop, invalid->net. -- http://mail.python.org/mailman/listinfo/python-list
