Newcomer struggling with tutorial

[logistix at cathoderaymission.net]

CPK Smithies <cpks at NOspam.btopenwhirled.com> wrote in message news:<blpf2k$fef$1 at titan.btinternet.com>...
> "Tim Peters" <tim.one at comcast.net> wrote in
> news:mailman.1065325869.29360.python-list at python.org: 
> 
> > Perhaps that's confusing you.).
> 
> Yes. I screwed up with my example and I'm sorry to waste people's time. I 
> was getting confused.
> 
> What I found so disturbing is that
> 
> a < b == c
> 
> is not equivalent either to
> 
> (a < b) == c
> 
> nor to
> 
> a < (b == c)
> 
> since (given that for example (a, b, c) == (-1, 77, 1)) the first is false 
> while the latter are both true. 
> 
> Perhaps some people enjoy mastering quirks like these. I just see it as a 
> source of confusion and errors. What's so terrible about having to type "(a 
> < b) && (b == c)" if that's what is intended? Is it really worth 
> sacrificing a logical grammar for the sake of a few keystrokes? So it's not 
> a bug in implementation that I'm talking about. It's a bug in the design.

As a side note, the boolean values True and False evaulate to 1 and 0
respectively.  When you use parenthesis, you are forcing precidence
which causes the return of either True or False values and breaks the
chaining.  These will then act like integers in subsequent operations.

>>> True + 1
2
>>> False - 1
-1
>>> (73 < 99) + 1
2

This primarily affects the test case you have of (a < b) == c, where
you are really testing to see if "True" is equal to 1 (which it is).