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

[Peter Pearson]

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.