question about True values

[Antoon Pardon]

On 2006-10-27, Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> wrote:
> On Fri, 27 Oct 2006 09:16:57 +0000, Antoon Pardon wrote:
>
>>> I think it is a good time to remind people of some extremely well-thought
>>> out opposition to the introduction of bools to Python from Laura Creighton:
>>>
>>> http://mail.python.org/pipermail/python-list/2002-April/095878.html
>>>
>>> She lost the debate, Guido had the final word and Python now has bools.
>>> Take particular note of her description of Python distinguishing between
>>> Something ("cat", 4, [0, 1, 2] etc) and Nothing ("", 0, [] etc).
>> 
>> Yes and IMO that is a less usefull distinction than the distinction
>> between True and False. When I write code I think in terms of
>> conditions. In those conditions this has to be treated this way
>> otherwise it has to be treated an other way. Conditions give
>> results that are either True or False, not Something or Nothing.
>
> And if you read the thread that Laura Creighton's post is part of, you
> will see that she acknowledges that most people think strongly in terms
> of binary true/false yes/no states, and that this is often the wrong thing
> to do. There are lots of human thought patterns that are unhealthy, and
> binary is often one of them.

The Nothing/Something dichotomy is just as binary as the True/False
dichotomy. And in the case of deciding whether you will take the
"then" branch or "else" branch I see nothing unhealthy in checking
whether the condition was true or not.

> The world is continuous, and our brains think in binary. No wonder people
> have such trouble with concepts like evolution:

The world may be continuous, programming structures are discrete.
You take the "then" branch or not. In the latter case you can
again decide to take the elif branch or not. There is nothing
continuous in that.

> - there is a continual chain of individuals such that every offspring of
> an reptile is a reptile, and every parent of a mammal is a mammal, and
> yet mammals are directly descended from reptiles.
>
> By I digress. This is too easy to get off topic...
>
>
>> I don't think of 10 > 5 as Something while 5 < 10 would be
>> Nothing. 
>
> Not at all, you got your operators the wrong way around. Five certainly is
> less than 10 in every counting system I've ever come across. I think you
> meant 5 > 10 is Nothing.

Yes that was a type, I meant I don't think of 5 > 10 as Nothing.

> Certainly purely mathematical relations like GT and LT lend themselves
> very well to true two-valued algebra. The thing to remember is that
> Python's truth model is not the same as pure Boolean algebra. For
> starters, it certainly is not two-valued! It is infinitely-valued. It's
> just that many of those values are equivalent *in a Boolean context*.

That it is infinitely-valued is a red herring. It is partitioned in
two, so all these infinite values are mapped into two possibilities
because at the end you have to decide a simple yes/no question.
Will I repeat the loop or not. Will I take the "then" branch or
not.

> In Pascal, writing "x := 2; if x then..." would be an error, because x is
> not a Boolean. But it is certainly useful to be able to write the
> equivalent in Python. The designer of Pascal choose strict Boolean
> algebra; the designer of Python choose a more flexible, less strict model.
>
> If you are going to argue for strict Booleans, like in Pascal, then
> mathematical relations like GT and LT will be your poster-child. 
>
> But if you are going to argue for Python's less strict truth model, then
> you'll talk about lots of examples like this:
>
> if somelist:
>     # work with the list
> else:
>     # nothing to work with

In most case I just do:

  for el in somelist:

which works for empty lists just as good as non-empty ones. So
why should an empty list be treated differently from an non-empty
one if it is used in a boolean context?

>> So while the paradigma of the language may be the
>> distinction of Something vs Nothing the programmer will often
>> enough think in terms of True and False. 
>
> If you read Laura's post, you will see that she is arguing strongly that
> thinking about True and False is often -- usually! -- a mistake.

Yes she argues that? So? I think she is wrong and her argument
lacking.

> I
> acknowledge that there are cases where it is either necessary or desirable
> to think in terms of True/False, but that is less common than you might
> think.

Control structures in programming languages do nothing else but decide
things in terms of True/False. You may dress things up but in the
end a statement like:

  if obj:

Will evaluate/map into a two valued domain, where one value will lead you
into the "then" branch and the other value will not. And IMO the more
clearer the relationship between the written code and the final result
the better.

-- 
Antoon Pardon