Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Sat, 16 Jul 2016 10:33 pm, Rustom Mody wrote:

> You also have a bizarre notion that python's property: “Everything has
> auto-bool-nature” IS STRAIGHTFORWARD.

That's a very strong claim.

You're not just pointing out that there may be a few old corner cases here
and there where Python's treatment of bools fails to be straightforward, or
is a little harder than it appears at first glance. You're making the claim
that it is BIZARRE (grossly unconventional or unusual, beyond belief,
foolish, laughable, ludicrous, nonsensical, outrageous, ridiculous, crazy)
to think that it might be straightfoward. In other words, that it is
obviously, clearly not-straightforward.

If you really mean your words, and don't wish to step back and make a less
extreme claim, then you ought to be easily able to show that Python's use
of bools hardly ever works. It's clearly a terrible idea, almost every use
of it is a failure, even Blind Freddy can see that it is hard to use and
not straightforward.

The truthiness API is straightforward. Any value or object is usable in a
boolean context, and there is a well-defined protocol for deciding whether
arbitrary objects are considered true or false:

* If the class defined a __nonzero__ (or __bool__ in Python 3) method, then
the truthiness of the object is given by the result of calling that method.

* If there is no __nonzero__ (or __bool__) method, but the class defines
__len__, which returns zero, then the object is deemed falsey, otherwise it
is deemed to be truthy.

* If the class lacks both dunder methods, then the object is deemed truthy.

This should not be hard to understand. So what part of this system is not
straightfoward?


(1) Is it that programming the required dunder methods is not necessarily
trivial for every imaginable object? Nobody said that had to be.


(2) Is it that it may be tricky for the designer of the class to map the
class values/objects into the true/false dichotomy? Python gives a simple
and, yes, straightforward metaphor to use: if an object represents nothing
(an empty container, null, void) then it should be falsey, otherwise it
should be truthy.

But that doesn't mean that every imaginable class trivially maps into that
dichotomy. Suppose we create a tri-state logic class, with three states
Yes, No and Maybe. Obviously Yes should map to True, and No to False. What
should Maybe map to? We may spend many sleepless hours weighing up the pros
and cons of mapping Maybe to True versus Maybe to False. Or we might flip a
coin.

And yes, Rustom, I'm very familiar with the philosophical objections to the
something/nothing distinction. "Is zero truly nothing, or is it some thing
distinct from the absence of any number?" I'm not interested in that
argument. Let the philosophers count angels, but as far as Python code
goes, I'm an intuitionist: if I have zero sheep, that's the same as not
having any sheep, or having no sheep.

I'm more sympathetic to the view that an empty list is different from
absence of a list, therefore it's something, not nothing. Fine, if that's
the way you want to reason, go right ahead and do so when you write your
own language. But in Python, practicality wins, and empty sequences and
collections are treated as "nothing". (It's a metaphor, not a deep
philosophical axiom.)

(3) Is it that sometimes people write code involving boolean contexts that
may not be trivially understood and obviously bug free? Sure they do. So
what? Do you expect perfection of code for every feature?

(4) Or something else? If so, what is your basis for claiming that this is
not straightforward? What part, or parts, is not straightforward?




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.