[Tutor] beginning to code

[Antoon Pardon]

Op 19-09-17 om 11:22 schreef 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(): ...

IMO not very much, in real life code, the latter code would probably
much more clear than the former.

> 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.

I am not so sure about strings. Otherwise there would be no need for
all those formatting possibilities, that python provides. That the
object knows how to convert itself to a string, doesn't mean it is
the string that is useful to the user.

> 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*

On the other hand, python is very eager to convert objects to a bool. For
strings and iterators you are expected to write a dunder method. If you
think it makes no sense to see specific instances as true or false, you
have to explicitly write a __bool__ that raises an exception. I think
it would have been a better choice that a TypeError would have been
raised if __bool__ wasn't defined.
 

>> 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 I was talking about how I *think* about those things. That after
implementating these thoughts in python, python will cast all those
things in the various concepts of truthy, doesn't contradict that
was/is not how I approach(ed) the problems to be solved.

-- 
Antoon Pardon