4 ms·

Yeah, the behavior is arguably much less confusing than the alternative of: 5==5==5 # All three the same (5==5)==5 true==5 false Or 1==

by Terr_ 2y ago

Yeah, the behavior is arguably much less confusing than the alternative of: 5==5==5 # All three the same (5==5)==5 true==5 false Or 1==2==false # All three different, in a troublesome way (1==2)==false false==false true

zdragnar 2y ago
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.
- furyofantares 2y ago
  > 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.
- pansa2 2y ago
  > 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.

by Terr_ 2y ago

zdragnar 2y ago

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.

furyofantares 2y ago
> 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.
pansa2 2y ago
> 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.