[Tutor] beginning to code

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

> 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. If you want an argument
worth having, go argue with the Perl people about the fact that "0"
(the 1-character string containing a zero) is false in Perl:

> perl -e "print qq'a non-empty string that is false\n' if not '0';"
a non-empty string that is false

Given this sort of silliness, I'm perfectly OK with the choices Python made :-)

Paul