[Tutor] beginning to code

[Steven D'Aprano]

On Tue, 19 Sep 2017 09:10:04 +0200, Antoon Pardon wrote:

> Op 18-09-17 om 15:47 schreef Paul Moore:
>> On 18 September 2017 at 14:30, Antoon Pardon <antoon.pardon at vub.be>
>> wrote:
>>> Well that you reduce an object to a boolean value is not obvious to
>>> begin with. A TypeError because you are treating a non-boolean as a
>>> boolean would have been more obvious to me.
>> More obvious, possibly - that's essentially a matter of what people are
>> used to, and a measure of personal opinion.
>>
>> More useful? Unlikely. The practical examples I've seen of languages
>> like Python that implicitly convert non-boolean values to boolean, and
>> languages that don't (and raise an error if a non-boolean is supplied
>> to an if statement) suggest to me that implicit conversion is highly
>> useful. I certainly use it in my code (although in my view it's
>> perfectly "obvious", so I may use constructs that you would find
>> non-obvious).
> 
> I don't find it really usefull. How useful is it that you can type if a:
> instead of if a != 0: ? 

How useful is duck-typing?

How useful is it to type:

    if a or b or c: ...

instead of:

    if a.condition() or predicate(b) or c.somecondition(): ...


Objects already know how to convert themselves to strings, to generate a 
repr, how to convert themselves to an iterator (if possible), etc. We 
don't hesitate to duck-type any of these things and expect objects to 
manage their own conversions.

Except for bools, where people freak out and are convinced the world will 
end if you just ask an object "are you true or false?". 

Perhaps just a *tiny* exaggeration *wink*

> I have yet to encounter a situation where I
> thought: Yes I want to execute this piece of code when a value is Falsy
> and an other piece when that same value is Truthy.

But that's exactly what you've done with "if a != 0". You *literally* 
executed code according to the truthiness of a. Only you did it with more 
typing.

But for what its worth, I do allow that comparing numbers to zero is 
sometimes the right thing to do. Sometimes you're not treating zero as a 
falsey value, its just another number that happens to need special 
treatment. In this case, it might not be appropriate to duck-type your 
number as a bool, when your intent is specifically to compare it against 
a value which merely happens to be zero.


Especially for pure mathematical functions:

def sinc(x):
    if x == 0:
        return 1
    else:
        return sin(x)/x

and even more so if 0 is just one case out of many:


def somefunc(x):
    if x == -1:
        ...
    elif x == 0:
        ...
    elif x == 1:
        ...
    else:
        ...


> What usually happens, is that the programmer expect only values from a
> specific domain and that as long as that restriction is obeyed, he can
> express what he wants in terms of truthy and falsy values, but it
> doesn't mean that he wants False, None and [] treated the same way.

Then don't treat them the same. You always have the option of writing 
code which is as finicky and idiosyncratic as you want:

if x is False:
    ...
elif x is None:
    ...
elif x == []:
    ...



> So I find code that uses the domain specific condition more clear and
> less error-prone than code that abstracts that domain specific condition
> into the truthy-falsy distinction python makes.

"Less error-prone" -- got some examples of the errors that duck-typing 
truthiness causes?



-- 
Steven D'Aprano
“You are deluded if you think software engineers who can't write 
operating systems or applications without security holes, can write 
virtualization layers without security holes.” —Theo de Raadt