Typically we write a < b < c
as a shorthand for a < b
, b < c
, and a < c
. Assuming this is the case and <
, >
, <=
, >=
are transitive, which is usually the case, writing a < b > c
would imply that a < b
, b < c
, and a > c
, which is always false. Writing a <= b > c
could be true if and only if a = b
and b > c
, but this is still not the interpretation that Python has.
In Python, writing a < b > c
means a < b and b > c
, no comparisons are made between a
and c
, meaning the statement could be true. Similarly, the interpretation of a <= b > c
is completely different as there are many cases where a != b
and the statement is still true.
print(3 < 5 > 4) # Prints `True`
While the a op c
comparison in the a op b op c
example is not something we can actually infer, and the correct mathematical interpretation is, in fact, a op b and b op c
, this is an expectation that many people have when they see a chained comparison (as demonstrated by how unpopular the a < b > c
notation is).
This notation is not technically mathematically unsound, but it is uncommon and uncomfortable. When we are habituated in thinking by the reasoning presented in the first paragraph, this notation makes us stop and think just a little bit harder even if it is by a split second, creating friction and making it harder to understand the actual logic of the algorithm. We must remember code is read quite a lot. The subversion of expectations when seeing a a < b > c
comparison makes it really hard to track the code logic and could be more clearly represented with a < b and c < b