Can we make a SyntaxWarning for `if x == 2 or 3:`?

I’m in Serhiy’s camp. Syntax warnings should be used very sparingly.

3 Likes

Maybe the solution here is a feature request for IDEs, particularly those used by beginners: highlighting and/or text coloring to indicate the ordering of boolean evaluation.

I don’t know how best to format it (and different IDEs might make different choices), but I’m imagining something akin to how rainbow parentheses are used. The idea is to give a hint about how x == 2 or 3 is evaluated like “if x == 2 or 3”. I used underline here because the formatting supports it, but text color could also work. And of course this can be an option that gets turned off.

Adding my two cents because it feels close to a check in pylint called “bad-chained-comparison”. There are operator that have a different semantic meaning: comparison (==, !=, <, etc.), membership (in, not in) or identity (is, is not). For example in x in primes is z not in primes or left is None != right is None, or "parrot" in result is not "passed away" some operators are semantically incompatible with each other and it’s very likely the code is not doing what was intended.

Also, it seems even seasoned python devs can make this kind of mistakes or be blind to it in review because it caught a bug in sentry (Fix ``bad-chained-comparison`` in ``api/endpoints/project_details.py`` by Pierre-Sassoulas · Pull Request #42669 · getsentry/sentry · GitHub).

Imo this kind of mismatched chained comparisons could be a syntax error directly in python.

But the example from the question was impossible to add in the bad-chained-comparison check because x == y or z is valid python and would have caused a lot of false positives (maybe we even had to see the result of primers to realize it). There’s still a message for it in pylint at a lower “refactor” level (R1727: Boolean condition 'x == 2 or 3' will always evaluate to '3' (condition-evals-to-constant).

1 Like

To continue this train of thought, I’d personally agree that the boolean True and False should definitely be treated as “plausibly intentional” in this regard. With that said, using the two specific integer literals 1 and 0 as single-character boolean shorthand seems perfectly reasonable to me, so I think those cases could also plausibly be considered intentional uses of their inherent truthy/falsey-ness. I think these cases should probably be ignored if they would otherwise be flagged.

However, I suppose this definition technically includes -1 since the unary operator is not strictly part of the literal. That said, adding a unary +/- should probably override the special case of literal 1 or 0. I don’t see any case where someone uses +1 as shorthand for True but could imagine a beginner writing if x == -1 or +1: for instance.

Along those lines, all literal floats (including 0.0 and 1.0, since those make a terrible shorthand), strings, bytes, etc. are also probably not intentionally being used explicitly for their booleanness in this sort of context, so IMO those cases should all be flagged with a SyntaxWarning if one were to be implemented at all.

1 Like