1 > 0 == True -> False

[Rustom Mody]

On Thursday, January 30, 2014 8:39:03 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 30 Jan 2014 09:08:58 -0500, Roy Smith wrote:

> > 1) Assume that you don't have the full operator precedence table
> > memorized and just parenthesize everything.

> Oh really? Do you actually write stuff like this?

> b = ((2*a) + 1)
> if (b >= (-1)):
>     ...

> I would hope not.

> > 2) In cases where the expression is so simple, you couldn't possibly be
> > wrong, see rule #1.

> Or, you can avoid superstitious responses *wink*

> (1) Learn the operator precedences to the best of your ability. It's
>     not hard, most of it works just like the precedences you're used
>     to from maths class (remember that?) or in the most intuitively
>     useful way.

>     E.g. `1 + x == 2` does the useful thing of calculating 1 + x 
>     before testing for equality, rather than the stupid thing of
>     calculating x == 2 first then adding it to 1.

> (2) When in doubt, use parentheses.

> (3) When the expression is complex, a few extra parentheses can
>     help make it easier to understand. "Seven, plus or minus two"
>     is (roughly) the number of distinct items the human short-
>     term memory can hold. Grouping terms together can help reduce
>     the distinct number of items the reader needs to keep in 
>     short-term memory.

>     E.g. `x+1 > 0 and y >= 5` is potentially as many as 9 distinct
>     items to keep in short-term memory. But bracketing some terms 
>     as in `(x+1 > 0) and (y >= 5)` can reduce that down to as few
>     as two items.

> (4) But too many parens obscure the meaning of the expression too. Aim
>     for a good balance, neither too few nor too many. Your judgement 
>     of the right number of parens is a skill, which will come with 
>     experience.



(5) use APL -- all ordinary operators group right to left and at the same
precedence level