Operator Precedence/Boolean Logic

[Rustom Mody]

On Sunday, July 17, 2016 at 4:32:36 PM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 17 Jul 2016 04:44 pm, Rustom Mody wrote:
> 
> > My earlier statement (with emphasis in original):
> >> You also have a bizarre notion that python's property: “Everything has
> >> auto-bool-nature” IS STRAIGHTFORWARD.
> 
> I'm still waiting to hear in what way it is not straightforward. You keep
> insisting that it isn't, but haven't told us in what way it is not.

The re/automaton/graph examples were towards this only and I think we are 
running in circles on this.  [Note the persons involved and even the specific
types involved are in a sense not relevant]

There is however one point that I briefly alluded that can be expanded on, viz.
Python’s bool behavior is inconsistent with rest of python’s standard behavior.

>>> class C:
...   pass
... 
>>> c=C()
>>> c+c
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'instance' and 'instance'
>>> c.a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: C instance has no attribute 'a'
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

IOW the details — AttributeError/NameError/TypeError — may differ but in general
python has a well-established (and IMHO kind) behavior, if programmer fails
to define something python helpfully says that and makes no random guesses.

The extremal behavior at the other end of the spectum is probably html:
Whatever html you throw at whatever browser it will be rendered in some way 
or other.  [Some people like this — standards are for wimps]

For bools python is closer to html than to its normal peremptory default:

>>> if c:
...   print "Yes"
... else:
...   print "No"
... 
Yes