Operator Precedence/Boolean Logic

Steven D'Aprano steve at pearwood.info
Sat Jul 16 05:14:45 EDT 2016


On Sat, 16 Jul 2016 03:58 pm, Rustom Mody wrote:

> 
> From other thread:
> 
> On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
>> On 07/15/2016 09:04 PM, Rustom Mody wrote:
>> 
>> > Just that suggesting that python's bool notion is straightforward is an
>> > unnecessary lie – especially to newbies.
>> 
>> Python's boolean concept is as simple as it gets -- what is not
>> straightforward about it?
> 
> And to expand on my
> 
> On Saturday, July 16, 2016 at 11:18:48 AM UTC+5:30, Rustom Mody wrote:
>> FWIW My belief: In general its nonsensical
> 
> C's 0 is false; rest-of-universe is true is a mess

Really? In what way?

As far as I know, C requires bools to be ints, not arbitrary values, and the
compiler will enforce that. What mess do you get from C allowing 2 as well
as 1 to be treated as true?


> Python increases the mess by making the false-y candidates also
> non-singleton

So you say, but you haven't demonstrated this.


> This seems to work for container-like objects like lists,strings,sets, etc
> with None and 0 being somewhat elliptical analogues

Right. This is a good, concrete, practical example that duck-typed truthy
and falsey values DOES work: it works for numbers, it works for strings, it
works for containers.


> But when we allow __bool__ to be available for any and every thing and
> give it some implicit random definition, this is just plain nonsense.
> 
> [What is the bool-nature -- aka Buddha-nature -- of graphs question
> [remains yet answered]

No, I already answered that in the earlier thread. Graphs are collections or
sequences of nodes. An empty graph (one with zero nodes) should be falsey;
all other graphs (one or more nodes) should be truthy.

I say "should", not "must". Practicality beats purity: if your application
has a specific need for (let's say) a graph with exactly two cycles to be
considered falsey, and all others to be truthy, then you are free to define
your graph type that way. As an internal application-only class, that's
probably okay, but as a generic graph type in a library, it's probably a
bad idea.




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




More information about the Python-list mailing list