7 ms·

If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and

If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.

toomanyrichies 2y ago
> It's not Python that's confusing, it's your previous experience with other languages that's confusing you. "There are no children here at the 4H club either! Am I so out of touch? No... it's the children who are wrong." -Principal Skinner, "The Simpsons" EDIT to clarify- I'm just being silly, not suggesting anyone is right or wrong here.
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.
ball_of_lint 2y ago
Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd prefer languages that I work with to chose earlier options from that list. In most languages this sort of statement is usually a bug, and deserves explicit parenthesis to clarify the order of operations. I really don't want to have to pull out an operator precedence chart in order to read your code, much less have to look up some esoterica about this specific language.
- throwaway313373 2y ago
  "someone who writes code" is very vague. For someone who writes code primarily in Python this behavior is less surprising than the rest that you described.
  - ball_of_lint 2y ago
    Intentionally so. I've worked primarily in Python for the last two years and I'd still have to look at a reference to be certain of what exactly this code does. And would probably rewrite it to the expanded, parenthesized form unless the company linter insisted.
- atoav 2y ago
  I'd argue that many programming languages are not optimized for "people who read code" but they are optimized for programs who read code (compilers, interpreters) and programmers can stockholm-syndrome themselves into believing that it is targeted at them.
  - James_K 2y ago
    Code optimised for an interpreter is often also optimised for the programmer, whose primary job is interpreting code. What makes natural language intuitive is that it doesn't have to be precise. You can assume language does what it is intended to do. A programmer, by contrast, must know exactly what the program does. You cannot assume it does what you want it to do because the computer doesn't know what you want it to do. A language cannot be made less precise by the addition of new rules; it is only made more complicated as there is more to remember. In this example, the person writing the ternary expression had to learn that it exists. If it didn't exist, there would have been less learning to do. Perl is the limit of this process – a language with many rules to appear natural and human-like that it's almost impossible to actually read. Each rule of a language is a cognitive burden. It can only justify itself if the thing it replaces is a greater burden.
alkonaut 2y ago
What does A == B == C even mean? I mean I know what mathematically A=B=C means. That A, B and C are all equivalent. But then is the mathematical '=' really a binary operator that maps two numerical inputs to a boolean output? It feels then as an abuse of notation if (A=B)=C doesn't allow A=B to change type? Because I don't really have much use for a symbol that is some times doing a binary mapping from numbers to booleans and some times becomes some sort of ternary operator which maps 3 inputs to one boolean.
- joveian 2y ago
  Maybe consider chained comparison operators early textual replacement along the lines of the C preprocessor, although the exact textual replacement would involve temporary variables to avoid multiple side effects and be more complicated than just "(a) == (b) and (b) == (c)". (a==b)==c does not expand, only the version without parentheses expands, so you can still do the boolean comparison if you want.
TrainedMonkey 2y ago
I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is overloaded with binary comparison operator, so the people will be confused. This actually gets weirder - in python you can make an arbitrary long comparison operator - it's called comparison chaining - https://www.programiz.com/online-compiler/6uyqb52IVH8if https://www.programiz.com/online-compiler/6uyqb52IVH8if . It works with a lot of operators - https://www.geeksforgeeks.org/chaining-comparison-operators-python/ https://www.geeksforgeeks.org/chaining-comparison-operators-... Once you know how it works and are used to it, I think it makes the code easier to parse... but there are heavy downsides. For example, it's not clear how short circuiting works. I've used python a bunch and logically I expect ```side_effect3()``` to not be evaluated if results of 1 and 2 are not equal: ```side_effect1() == side_effect2() == side_effect3()```. However, I do not know that for sure, while in other languages I would be able to reason about this from basic principles.
- Ukv 2y ago
  > the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.
  - redditor98654 2y ago
    Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.
    - lordnacho 2y ago
tmtvl 2y ago
Yet another way in which Lisp is vastly superior to any and all blub languages: (= 2 (+ 1 1) (sqrt 4)) ; => t (< most-negative-fixnum 0 most-positive-fixnum) ; => t
- Aachen 2y ago
  I have no idea what this does or if you are joking. Could use some explanation
  - gus_massa 2y ago
    In Lisp, you put the "operator" first, so instead of 2 + 3 + 4 you write (+ 2 3 4) This is nice for associative operations like + or *, very very very slightly confusing for - and / --- You use the same style for comparisons, so instead of 2 == 3 == 4 you write (== 2 3 4) To support the fist "infix" syntax, you need some magic in the == operator. But the second "prefix" syntax is totally natural and you need no magic in the parser or the operator.
    - tmtvl 2y ago
      > very very very slightly confusing for - and / It's fine if you DNF it: (- a b c) => (+ a (- b) (- c)) (/ a b c) => (* a (/ 1 b) (/ 1 c))
    - Aachen 2y ago
      I knew that Lisp does this operator first thing, it's everything around this that I'm not familiar with. What does ; do? Is the => an arrow or greater than or equal to? What is t? Do I guess correctly that most-negative-fixnum is like INT_MIN?
      - tmtvl 2y ago
        The semicolon is Lisp syntax for comments. T is the way you write true in Lisp. Most-negative-fixnum is the most negative number Lisp can represent without promotion to bignum (so it can be int_min if int is roughly equivalent to size_t).
quietbritishjim 2y ago
> If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Sure, that's true if you literally know nothing about coding. But that is not a very common audience for reading code. You only need to spend about 10 minutes coding to realise that the compiler follows fixed rules rather than making an LLM-like guess as to the meaning. If you get that far then most people (admittedly after a bit more 10 minutes) go on to realise that the only way to know what code does is carefully pick it apart step by step, rather than glance at it and guess yourself. I love Python dearly, but this rule was a misstep on my opinion.
ninetyninenine 2y ago
The problem isn’t meaning or intent its inconsistency of operator behavior. 1 + 1 + 1 has different operator behavior then 1 == 1 == 1. The operations here are not consistent and it’s not clear what happens if I overload the operators. On the surface level python looks more beautiful. But mathematically speaking python is actually more ugly and more inconsistent with weird rules to make things look a certain way.
eacapeisfutuile 2y ago
If you know nothing about Python or coding it is not really relevant as the code is probably read and written more by those who know coding and/or Python?

toomanyrichies 2y ago

> It's not Python that's confusing, it's your previous experience with other languages that's confusing you. "There are no children here at the 4H club either! Am I so out of touch? No... it's the children who are wrong." -Principal Skinner, "The Simpsons" EDIT to clarify- I'm just being silly, not suggesting anyone is right or wrong here.

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.

ball_of_lint 2y ago

Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd prefer languages that I work with to chose earlier options from that list. In most languages this sort of statement is usually a bug, and deserves explicit parenthesis to clarify the order of operations. I really don't want to have to pull out an operator precedence chart in order to read your code, much less have to look up some esoterica about this specific language.

throwaway313373 2y ago
"someone who writes code" is very vague. For someone who writes code primarily in Python this behavior is less surprising than the rest that you described.
- ball_of_lint 2y ago
  Intentionally so. I've worked primarily in Python for the last two years and I'd still have to look at a reference to be certain of what exactly this code does. And would probably rewrite it to the expanded, parenthesized form unless the company linter insisted.
atoav 2y ago
I'd argue that many programming languages are not optimized for "people who read code" but they are optimized for programs who read code (compilers, interpreters) and programmers can stockholm-syndrome themselves into believing that it is targeted at them.
- James_K 2y ago
  Code optimised for an interpreter is often also optimised for the programmer, whose primary job is interpreting code. What makes natural language intuitive is that it doesn't have to be precise. You can assume language does what it is intended to do. A programmer, by contrast, must know exactly what the program does. You cannot assume it does what you want it to do because the computer doesn't know what you want it to do. A language cannot be made less precise by the addition of new rules; it is only made more complicated as there is more to remember. In this example, the person writing the ternary expression had to learn that it exists. If it didn't exist, there would have been less learning to do. Perl is the limit of this process – a language with many rules to appear natural and human-like that it's almost impossible to actually read. Each rule of a language is a cognitive burden. It can only justify itself if the thing it replaces is a greater burden.

alkonaut 2y ago

What does A == B == C even mean? I mean I know what mathematically A=B=C means. That A, B and C are all equivalent. But then is the mathematical '=' really a binary operator that maps two numerical inputs to a boolean output? It feels then as an abuse of notation if (A=B)=C doesn't allow A=B to change type? Because I don't really have much use for a symbol that is some times doing a binary mapping from numbers to booleans and some times becomes some sort of ternary operator which maps 3 inputs to one boolean.

joveian 2y ago
Maybe consider chained comparison operators early textual replacement along the lines of the C preprocessor, although the exact textual replacement would involve temporary variables to avoid multiple side effects and be more complicated than just "(a) == (b) and (b) == (c)". (a==b)==c does not expand, only the version without parentheses expands, so you can still do the boolean comparison if you want.

TrainedMonkey 2y ago

I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is overloaded with binary comparison operator, so the people will be confused. This actually gets weirder - in python you can make an arbitrary long comparison operator - it's called comparison chaining - https://www.programiz.com/online-compiler/6uyqb52IVH8if https://www.programiz.com/online-compiler/6uyqb52IVH8if . It works with a lot of operators - https://www.geeksforgeeks.org/chaining-comparison-operators-python/ https://www.geeksforgeeks.org/chaining-comparison-operators-... Once you know how it works and are used to it, I think it makes the code easier to parse... but there are heavy downsides. For example, it's not clear how short circuiting works. I've used python a bunch and logically I expect ```side_effect3()``` to not be evaluated if results of 1 and 2 are not equal: ```side_effect1() == side_effect2() == side_effect3()```. However, I do not know that for sure, while in other languages I would be able to reason about this from basic principles.

Ukv 2y ago
> the symbol it is using is overloaded with binary comparison operator, so the people will be confused I think most people would expect expressions like `5 < x < 10` to work as they do in math, without necessarily thinking about it in terms of being an overloaded binary operator. The result in other languages that `5 < 12 < 10` = `true < 10` = `true` is more surprising, just that we've (perhaps by being bitten by it early on) gotten used to it.
- redditor98654 2y ago
  Yeah, but should that math equivalence hold for programming though? Programming is different. x=x+1 is perfectly legal in programming but does not make sense in algebra math and could confuse mathematicians.
  - lordnacho 2y ago

tmtvl 2y ago

Yet another way in which Lisp is vastly superior to any and all blub languages: (= 2 (+ 1 1) (sqrt 4)) ; => t (< most-negative-fixnum 0 most-positive-fixnum) ; => t

Aachen 2y ago
I have no idea what this does or if you are joking. Could use some explanation
- gus_massa 2y ago
  In Lisp, you put the "operator" first, so instead of 2 + 3 + 4 you write (+ 2 3 4) This is nice for associative operations like + or *, very very very slightly confusing for - and / --- You use the same style for comparisons, so instead of 2 == 3 == 4 you write (== 2 3 4) To support the fist "infix" syntax, you need some magic in the == operator. But the second "prefix" syntax is totally natural and you need no magic in the parser or the operator.
  - tmtvl 2y ago
    > very very very slightly confusing for - and / It's fine if you DNF it: (- a b c) => (+ a (- b) (- c)) (/ a b c) => (* a (/ 1 b) (/ 1 c))
  - Aachen 2y ago
    I knew that Lisp does this operator first thing, it's everything around this that I'm not familiar with. What does ; do? Is the => an arrow or greater than or equal to? What is t? Do I guess correctly that most-negative-fixnum is like INT_MIN?
    - tmtvl 2y ago
      The semicolon is Lisp syntax for comments. T is the way you write true in Lisp. Most-negative-fixnum is the most negative number Lisp can represent without promotion to bignum (so it can be int_min if int is roughly equivalent to size_t).

quietbritishjim 2y ago

> If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Sure, that's true if you literally know nothing about coding. But that is not a very common audience for reading code. You only need to spend about 10 minutes coding to realise that the compiler follows fixed rules rather than making an LLM-like guess as to the meaning. If you get that far then most people (admittedly after a bit more 10 minutes) go on to realise that the only way to know what code does is carefully pick it apart step by step, rather than glance at it and guess yourself. I love Python dearly, but this rule was a misstep on my opinion.

ninetyninenine 2y ago

The problem isn’t meaning or intent its inconsistency of operator behavior. 1 + 1 + 1 has different operator behavior then 1 == 1 == 1. The operations here are not consistent and it’s not clear what happens if I overload the operators. On the surface level python looks more beautiful. But mathematically speaking python is actually more ugly and more inconsistent with weird rules to make things look a certain way.

eacapeisfutuile 2y ago

If you know nothing about Python or coding it is not really relevant as the code is probably read and written more by those who know coding and/or Python?