and [True,True] --> [True, True]?????
ppearson at nowhere.invalid
Tue Apr 21 17:51:00 CEST 2009
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
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.
More information about the Python-list