Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 11:39 schreef Steven D'Aprano:
> On Thursday 23 June 2016 17:58, Antoon Pardon wrote:
>
>> Op 23-06-16 om 05:59 schreef Steven D'Aprano:
>>> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
>>>
>>>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>>>> [snip]
>>>>> I feel that’s a needlessly complicated rule. It would have been simpler
>>>>> if boolean operators (and conditional expressions like in if-statements
>>>>> and while-statements) only allowed values of boolean types. But that’s
>>>>> one of the few warts in the design of Python...
>>>>>
>>>> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
>>>> it enhances Python's
>>>> expressiveness.  Of course, everyone is entitled to their own
>>>> opinion...and this is mine.
>>> Allowing any value as a truth value is just applying the principle of
>>> duck-typing to booleans.
>> What does that mean? As far as I understood, duck typing was that you
>> could define any class with the same attributes and methods as an other,
>> often a built in, at which point you could substitute instance of this
>> new class anywhere you originally expected instance of the old class.
> But you only need to implement the behaviour you need, not the entire Duck 
> interface. If you only need quack(), you don't need to implement swim(), or 
> provide an actual Duck, any object capable of quacking will do.
>
> To decide on a branch, you don't need an actual bool, anything capable of 
> acting like a bool will do. As a language design, ALL objects are capable of 
> acting like a bool. Python has a specific protocol in place for deciding 
> whether an object quacks like a bool:

But an object acting like a bool, doesn't mean this bool behaviour makes the
disctinction you actually need. Python tempts people to rely on those truthy
values, because it saves typing is pythonic and it works for the moment and
then something unexpected gets passed through and you find yourself chasing
a very illusive bug. 

>> My experience is that this doesn't work with booleans. When I need
>> real booleans, encountering whatever else that can act like a boolean,
>> is more often than not an indication something went wrong but the
>> detection of it going wrong is delayed, because almost everything
>> can act like a boolean. It is why I have sometime found the need
>> to write:
>>
>>     if flag is True:
>>
>> Because flag needed to be True, not truthy.
> I find this hard to believe. Why do you care if somebody passes you 1 or "T" as 
> the flag instead of True? And if they do pass something other than True, you 
> don't get an exception, you simply take the false branch.
>
> Somehow I doubt that you write three-state logic everywhere:

Since I wrote above the I *sometimes* found this need. You may
safely assume I don't write it everywhere.

>
> if flag is True: ...
> elif flag is False: ...
> else: ...
>
>
> By the way, it is a particular error of folks using so-called "real bools" to 
> compare something you already know is a bool against True. I used to see it all 
> the time in my Pascal days, where people would define a boolean flag then write 
> "if flag == True". Given:
>
> assert isinstance(flag, bool)

But of course if one would show such a line in code on this
list, it would illicit a lot of comments on how unpythonic this
this is and that you really shouldn't, and that you should realy
rely on an exception being thrown when what you are provided
doesn't work.

You come here with a remark depending on not using duck typing
when you start your contribution with defending duck typing.

-- 
Antoon.