[Tutor] beginning to code

[Chris Angelico]

On Tue, Sep 19, 2017 at 5:10 PM, Antoon Pardon <antoon.pardon at vub.be> 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: ? 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.

Okay. Let me ask you a different question.

Given that you can do this:

    if x > 5:

should you be able to do this:

    condition = (x > 5)
    if condition:

? If "no", then you've just downgraded booleans to less than
first-class values. If "yes", then you've just opened up the
possibility for "if x:", and you have to draw the line somewhere -
what can you and what can't you use that way? It's now syntactically
legal to use "if x:" with any type of object, so you have to either
define the truthiness/falsiness of everything, or have some of them
raise TypeError.

ChrisA