That actually proves my point. I'm not really good in learning certain facts by heart so if I see a < b < c it is going to take multiple seconds, likely followed by an internet search so add a couple of minutes to that, before I can be 100% sure what it does. I mean, I know what precedence is and I'd probably assume it would be (a < b) < c but that's not going to cut it.

Just program in assembler then.

Honestly, Python's way is the only sane way to parse this. This is how a human who never programmed before with some knowledge of math would understand it.

Everyone's else mind is just corrupted by broken legacy languages.

I sometimes teach programming to beginners who have some knowledge of math. A common mistake they make is to write compound conditionals like this:

    if a == 2 or 3:
        do stuff

because that's how they would write it in math. Does that mean Python is broken and should support that construct as well?

I believe COBOL supports this.

Even if Python's way was the only sane way of doing it (view which, btw, denotes having narrow experience with programming languages), that's irrelevant. GP's point was that different languages use different rules so, unless you use brackets, you won't easily know which precedence rules get applied.

Python’s edge cases are just as odd as every other language

  >>> a=16
  >>> a*a is a*a
  True
  >>> a=17
  >>> a*a is a*a
  False

“is”, “==“, and “=“ are all very different and none of them match their mathematical equivalents very well.

Not really familiar with Python. Do you know why the second statement evaluates as false?

Small integer caching: https://wsvincent.com/python-wat-integer-cache/

The objects for small integers are built-in and static, but 17^2 is too big, and so new integer objects are created when the expressions are evaluated. "is" checks if two expressions represent the same object in memory. "==" checks for equality of values.

CPython keeps an array for "small value" integers (I think in the range [-5, 256]). So when Python wants 256, it'll give you a reference to the existing object. Larger numbers require a brand new object.

`is` is identity comparison and in python everything is "object". It check if two variable refer to same object (location in memory) or not. So you should not expect that `a is b` for `a=1.2 , b=1.2` be true. In this case actually first expression returned True is weird. because 0-256 objects are cached and every instance of them refer to same object.

Math notation is just one of many possible notations, though. And math notation is not static throughout history.

True. But the syntax of almost all other languages are derived from the same basic math syntax we use commonly for at least since programming languages are a thing.

When you use a tricky language feature to improve readability, you can just add a comment to the link some piece of documentation for that behavior. It is still a trade-off, but it saves a bit of time and whenever I come across a place where past me did this, I am always appreciative.

Depends. For obscure behavior features, ok, for 'language features' I'm probably still going to pass. Because in this example case that would come down do

  # See stackoverflow/highlyupvoted/wtf/does/python/do/here
  # This is the same as (a < b) < c.
  x = a < b < c

whih is not clearer, not easier to parse and not faster to read and harder to maintain (leads to rot easily when variable names change) than the non-ambiguous other choice.

I would have skipped that second line and just left the line with the documentation link. If you are going to provide the equivalent code in a comment, you might as well just use the equivalent code.

In Clojure, and I assume other lisps as well, you can use the < operator in the same fashion. By merit of prefix notation it's also unambiguous regarding precedence.

  user=> (< 1 2 3)
  true

I'll be honest that I'm not a Clojure user, even with context I have no idea read that. Like every other language you have to be trained to read it correctly and is not intuitively obvious to everyone.

The rules are extremely simple and easy to grasp. And once you've grasped it, you'll never have to think twice about it.

Parentheses take precedence.

The first symbol is the operator (add, subtract, sum, multiply, etc.).

Everything else is operated on from left to right.

(+ 2 5 7)

2+5+7

It's also not a Clojure thing. It applies to all Lisps or related like Scheme.

All maths functions where it makes sense take arbitrarily many arguments. (+ 1 2 3) = 6. (< 1 2 3) = true. Everything in function position (directly after an opening paren) is either a function you want to apply or a macro you want to expand, except in a select few forms, such as binding forms and conditionals. The syntax of scheme is remarkably simple once you know the basics.

I have programmed python for about 20 years, and I still do stupid mistakes. I grooked all the r6rs scheme syntax in 20 minutes, except for (do ...) which somehow never sticks. It is also rarely used.

I have tried to evangelize scheme enough to know some people just don't like it, but for me it instantly clicked.

+ and = are pretty obvious but it can still be confusing. Take not=. Does (not= x y z) mean adjacent numbers are disequal (x≠y≠z, by analogy to + and =)? Or that no two numbers are equal? Or that at least two numbers are disequal? Different lisps pick different meanings.

Which lisps? I think I have only ever seen that in clojure (thinking it was a bad idea), and clojure seems scared of parentheses. (not (equal? x y z)) is clearer, but suffers from the same drawback as your question.

The problem I think is that not= returns true as long as any elements are non-equal, which means it is not analogous to +. I can't speak for clojure, but this is in line with all equality predicates in scheme, negated or not. A predicate that checked if any neighbours are not equal would in true scheme spirit probably be called not-any-neighbour-equal? :)

> In all others, a < b < c would be parsed as ((a < b) < c) which may or may not be a type error, but it's consistent with the other binary operators.

In APLish languages, it's (a<(b<c)).

Julia also do this:

    julia> 2<3<4
    true

Python follows math. Other languages made up something weird.

The only correct way to parse `a < b < c` for numbers is throwing a type error.

Python comes second for source code niceness, allowing you to compare numbers to booleans is common and shouldn't be.

But it doesn't compare a number to a boolean. It tests whether b is between a and c, in Python.

What I wrote wasn't very understandable.

In most languages, like C++, a < b < c ends up comparing a boolean to an integer. This should be a type error, but isn't.