[Tutor] beginning to code

[Antoon Pardon]

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

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.

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.
 

>> A second thought is that it isn't obvious that empty strings, lists ...
>> should be thought of as falsy. Sometimes I am treating a stream of
>> values/objects and when I ask for the next available items, i get
>> a string/list. An empty string/list in that context would mean that
>> nothing was available, but it is possible that more will be available
>> later and so could be treated just like a non-empty list/string.
> We can argue over the precise rules as to *what* boolean values Python
> chooses to take particular non-boolean values as meaning. I'm not
> going to have a blazing row over whether an empty string should be
> true or false. But equally, I'm not going to mount a campaign to
> change it. It's just not that important to me. 

Why do you find it necessary to say this? I'm not mounting a campaign
to change anything either. I just think people are to eager to use
the word "obvious" when defending certain design choices made in
python.

-- 
Antoon Pardon