I think this would be great.

I opened #92747

I could see this being useful.

However, this need not be a problem if users are familiar with operator precedence rules or know where to look it up.

I do not think this should be added in the compiler. It will complicate the code for very tiny benefit. Such kind of mistakes are only made by beginners which learn programming. It is easy to catch when it happen the first time, and it is unimaginative that anybody make it the second time.

In contrary, the mistake in assert(condition, message) can be made even by experience programmer if he came from other programming language, and it is difficult to catch it, because it just "works", until it should fail, but do not fail, and in otherwise correct program it never fails.

It is easy to catch when it happen the first time

I have quite the opposite experience. I know a friend who was working on a non-trivial size program (hundreds of lines) when this happened to him for the first time. If I hadn't pointed it out in a review, the program would have behaved badly in a corner case that happens somewhat rarely. He didn't notice it himself when testing.

Hm, I'm sort of on the fence about this. On one hand, it is an extremely common issue on StackOverflow. This question has 1,294 questions linked to/from it including many, many duplicates.

I do buy the argument that the best tool to detect this is a linter, and needless complexity should be avoided, but I also think this might give a bit of benefit to beginners. I would defer to those with more experience teaching beginners though. I would assume that issue would be particular to those learning Python as their first programming language.

Hm, I'm sort of on the fence about this. On one hand, it is an extremely common issue on StackOverflow. This question has 1,294 questions linked to/from it including many, many duplicates.

I do buy the argument that the best tool to detect this is a linter, and needless complexity should be avoided, but I also think this might give a bit of benefit to beginners. I would defer to those with more experience teaching beginners though. I would assume that issue would be particular to those learning Python as their first programming language.

IMHO The proposed warning can only find a very limited subset of possibly problematic patterns without resulting in a high level of false positives.

The stack overflow question you link to is an example of that. That refers to "a or b or c == 2". In the context of that question it is clear that the OP should have used "a == 2 or b == 2 ...", but I've used similar code patterns where the code as written was correct.

That particular heavily-linked-to post isn't of a form that could be caught at compile time, but browsing the top 15 "Hottest" of those 1294 links, most of these could safely be made to emit compiler warnings without bothering anyone:

• if "a" or "á" or "à" or "ã" or "â" in someList:

• proceed="y" or "Y"

• if name == ("Jesse" or "jesse"):

• if fields[9] != ('A' or 'D' or 'E' or 'N' or 'R'):

• if job == "mechanic" or "tech":, (though this is a question "How do I do this better", not a mistake)

• if ('a' or 'b') in L:

• if x == "monkey" or "monkeys":

• if first == "a" or "e" or "i" or "o" or "u":

• if (len(x) == (4 or 6)) and x.isdigit():

• if user_input == "look" or "look around":

• if request == "y" or "Y":

• if choice == "yes" or "Yes":

• if not ( userDesc==("Y") or ("H") or ("E")):

• elif taxon == "Kids Earrings" or "Earrings":

There seems to be 3 different opinions about this:

1. Should be added to cpython
2. Complicates code too much and belongs to a linter (@rhettinger)
3. Complicates code too much and isn't useful

For opinion 3:

IMHO The proposed warning can only find a very limited subset of possibly problematic patterns without resulting in a high level of false positives.

I don't see how limited implies it's useless. Beginners use more hard-coded strings and ints in their if checks than experienced users, so restricting this to hard-coded values doesn't matter very much. The list above shows this quite clearly.

This one boils down to whether we want "simple is better than complex" or "practicality beats purity". To me, a warning like this seems very practical, while others prefer keeping the compiler simple.