Operator Precedence/Boolean Logic

[Rustom Mody]

Moved from thread "Assignment Versus Equality" where this is less relevant
============


On Wednesday, June 29, 2016 at 8:06:10 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 28 Jun 2016 12:10 am, Rustom Mody wrote:
> 
> > Analogy: Python's bool as 1½-class because bool came into python a good
> > decade after python and breaking old code is a bigger issue than fixing
> > control constructs to be bool-strict
> 
> That analogy fails because Python bools being implemented as ints is not a
> bug to be fixed, but a useful feature.
> 
> There are downsides, of course, but there are also benefits. It comes down
> to a matter of personal preference whether you think that bools should be
> abstract True/False values or concrete 1/0 values. Neither decision is
> clearly wrong, it's a matter of what you value.
> 
> Whereas some decisions are just dumb:
> 
> https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/

When we were kids we used to have 'pillow-fights' -- such fun!

So if we are in a link-pillow-fight here is a link
https://mail.python.org/pipermail/python-ideas/2016-June/040780.html
in which python-dev Nick Coghlan answers the question:

> Q: ...supporting arithmetical operations (1+True==2) was a primary
> intention, in which case my question is "why?".
> 
> Nick: The inheritance from int meant the default behaviour was to support
> type-promoting integer arithmetic operations in addition to bitwise
> arithmetic.
> 
> That changes the question from "Why support that?" to "Why do the extra
> design, documentation and implementation work needed to prevent that?".
> 
> The fact that "1 + True == 2" is surprising hasn't proven to be enough to
> motivate anyone to define the precise subset of operations they want to
> prevent, and then make the case for those restrictions as Python's native
> behaviour.


Well enough of link-ing.

There are many aspects of bool's ½-assed status as a legitimate bool-type
of which 1+True==2 is a silly but not very significant/expensive consequence.

More significant...

Steven D'Aprano wrote:

> So we have falsey values:
>  
> - None
> - zeroes (0, 0.0, 0j, etc)
> - empty dict {}
> - empty sets and frozensets
> - empty strings '' and b'' (in Python 2: u'' and '')
> - empty lists, tuples and other sequences
>  
> and truthy values:
>  
> - object
> - non-zero numbers
> - non-empty dicts
> - non-empty sets and frozensets
> - non-empty strings
> - non-empty sequences
>  
> This is an improvement over other languages like Javascript, Ruby, etc where
> the division between truthy and falsey appears to be fairly arbitrary.

Likewise and more strongly

Chris wrote :
> If your RedBlackTree object were always *true*, I'd
> call it a missing feature ("please add a __bool__ that distinguishes
> empty trees from trees with content"), but always *false* would be a
> bug. A SortedDict implies by its name that it should be extremely
> dict-like, so that would be a strong argument for its truthiness to
> follow a dict's. Either way, the misbehaviour gets pointed back at the
> object in question.

And Marko wrote:
> I don't particularly like Python's falsey/truthy semantics,
> but I can live with it. The biggest problem I have with it is the
> absence of an emptiness predicate. I'd like to be able to write:

<elsewhere>

> The point is, Python has already declared that __bool__ is the
> canonical emptiness checker. You could even say that it's the
> principal purpose of the __bool__ method.

In short,
- Steven hints that empty/non-empty is some sort of *generic* property of data structures
- Chris strengthens that to include types outside of builtins -- Red-Black trees
- Marko (thankfully adding the I dont like) connects emptiness to the dunder
__bool__

So here's some questions for the bool-fans

Please show me how we would define __bool__ for

1. Graphs -- the kind mathematicians define with "Let G =(V,E) be a graph..."

2. Automata which in a way are special kinds of graphs

3. Regular Expressions which mathematically are related to automata
  And pragmatically are (more) present in python than the first two

It may (or may not) be helpful to pretend that python which already has
a regexp module/type also has explicit regexp syntax a la Perl.