I dunno, I'd expect the right hand expression (2 == false) to be resolved first, then compared to 1.

Compare this with

    a = b = c = 5

You evaluate the innermost (i.e. the tail) expression first, and work your way out to the head. As a sexpr it is a little more obvious that way:

    (= a (= b (= c 5)))

An argument could easily be made that python is making up special rules for the equality operator by treating the duplication of the operator as merging the expressions into one.

Instead of what you would expect, per the rules of literally every other expression, 5 == 5 == 5:

    (== 5 (== 5 5))

It gets rewritten as

    (== 5 5 5)

Which one is "unexpected" is really a matter of perspective: are you reading with the rules of English or the rules of your programming language as your context?

I do concede one caveat to this argument: mathematical operators tend to change operator precedence around to avoid making mathematical mistakes. I am mildly of the opinion that this itself was a mistake. Most calculators don't do it, so it's not like anyone would be* that* thrown off by it.

> An argument could easily be made that python is making up special rules for the equality operator by treating the duplication of the operator as merging the expressions into one.

I guess the argument could be made but it would be wrong. All the comparison operators can be chained in python. a < b < c, for example, or even a == b <= c < d.

> You evaluate the innermost (i.e. the tail) expression first, and work your way out to the head. As a sexpr it is a little more obvious that way: `(= a (= b (= c 5)))`

That's not true in Python though.

    a = b = c = <expression>

is equivalent to:

    temp = <expression>; a = temp; b = temp; c = temp

I don't know why that order of evaluation was chosen.