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. -- https://mail.python.org/mailman/listinfo/python-list
