Some people find this legal syntax confusing:
A in B < C
I agree, that syntax definitely seems counter-intuitive. If it came up in a code review, I would request a revision to "A in B and B < C".
I feel like most code reviews would not allow this kind of code to be
checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it?
I can't personally imagine any practical use case for the syntax that couldn't be expressed differently in a way that's far more clear to readers. But, I don't think this is so much of a case of us choosing to *allow* the syntax, this seems to be more of a case where we don't explicitly *prevent* the syntax (through raising a SyntaxError).
From my experience, SyntaxError is raised primarily from clear mistakes that are easy to make (particularly for those who are new to the language or accidental typos) rather than simply syntax that is obscure, impractical, and/or hard to understand. It's realistically impossible to isolate every case of highly counter-intuitive usage of Python syntax, not to mention the resources it takes to implement a SyntaxError for each of them.
To me, it seems that the usage of "A in B <comparison_operator> C" is something that's not easy to do by accident, I can't imagine what someone would be intending to practically accomplish and mistakenly end up with that syntax, not knowing it could be expressed differently. A few important questions to consider:
1) Is this syntax misused enough to justify implementing a SyntaxError?
2) Would raising a SyntaxError help to point those who misuse it in the right direction?
3) Is it worth the resources it would take to implement the SyntaxError?
4) Does implementing the SyntaxError provide enough positive benefit to justify breaking backwards compatibility? Even if it's very rarely used and could be expressed differently, this still applies.
Also, in my opinion, the existence is a deterrent to Python and takes
away from Python's beauty as a language.
I would have to disagree, every language has its obscure corner cases and confusing ways to write expressions. I don't think the number of ways that users can misuse the language in an obscure manner to write confusing code should at all detract from it's beauty. If it were easy to misuse the language and *accidentally* write confusing code that would be one thing, but I don't think "A in B < C" is an example of that scenario.
As the others mentioned, I think the best solution to dealing with this type of syntax would be with a linter rather than directly preventing its usage.
(resent because the CC address was incorrect)
On Sun, Nov 17, 2019 at 6:01 AM Kyle Stanley aeros167@gmail.com wrote:
Some people find this legal syntax confusing:
A in B < C
I agree, that syntax definitely seems counter-intuitive. If it came up in a code review, I would request a revision to "A in B and B < C".
I feel like most code reviews would not allow this kind of code to be
checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it?
I can't personally imagine any practical use case for the syntax that couldn't be expressed differently in a way that's far more clear to readers. But, I don't think this is so much of a case of us choosing to *allow* the syntax, this seems to be more of a case where we don't explicitly *prevent* the syntax (through raising a SyntaxError).
From my experience, SyntaxError is raised primarily from clear mistakes that are easy to make (particularly for those who are new to the language or accidental typos) rather than simply syntax that is obscure, impractical, and/or hard to understand. It's realistically impossible to isolate every case of highly counter-intuitive usage of Python syntax, not to mention the resources it takes to implement a SyntaxError for each of them.
To me, it seems that the usage of "A in B <comparison_operator> C" is something that's not easy to do by accident, I can't imagine what someone would be intending to practically accomplish and mistakenly end up with that syntax, not knowing it could be expressed differently. A few important questions to consider:
Is this syntax misused enough to justify implementing a SyntaxError?
Would raising a SyntaxError help to point those who misuse it in the
right direction?
Is it worth the resources it would take to implement the SyntaxError?
Does implementing the SyntaxError provide enough positive benefit to
justify breaking backwards compatibility? Even if it's very rarely used and could be expressed differently, this still applies.
Also, in my opinion, the existence is a deterrent to Python and takes
away from Python's beauty as a language.
I would have to disagree, every language has its obscure corner cases and confusing ways to write expressions. I don't think the number of ways that users can misuse the language in an obscure manner to write confusing code should at all detract from it's beauty. If it were easy to misuse the language and *accidentally* write confusing code that would be one thing, but I don't think "A in B < C" is an example of that scenario.
As the others mentioned, I think the best solution to dealing with this type of syntax would be with a linter rather than directly preventing its usage.
On Sun, Nov 17, 2019 at 3:45 AM Neil Girdhar mistersheik@gmail.com wrote:
Some people find this legal syntax confusing:
A in B < C
(It means A in B and B < C.)
I feel like most code reviews would not allow this kind of code to be checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it?
If not, I suggest dividing the comparison operators into two groups:
in, not in, is, is not
and
<, >, <=, >=, ==, !=
and then disallowing chaining of operators from both groups.
For example, still allowed:
A <= B <= C
A in B in C
disallowed:
A < B in C
The advantage of such a change is that there is fewer "gotcha" code. I admit that this code is rarely written, but it can come up. For example, you might write your own comparison operator and then want to see if it's working:
A < B is None
returns false if B is not None even if A < B returns None.
Also, in my opinion, the existence is a deterrent to Python and takes away from Python's beauty as a language.
The downside of such a change is that the language is more complicated.
As far as implementation goes, this can be done after parsing when the AST is checked and errors are raised (from what I remember).
Best,
Neil _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/S7NBNT... Code of Conduct: http://python.org/psf/codeofconduct/
Kyle Stanley wrote:
I agree, that syntax definitely seems counter-intuitive. If it came up in a code review, I would request a revision to "A in B and B < C".
Please recall that chained comparisons such are
A < B < C
is to produce simple code when B is not an identifier, but an expression. For example
low < len(x) < high
or
inner ** 2 < x**2 + y**2 + z**2 < outer**2
which determines if (x, y, z) is in a spherical shell.
Even for "A < B < C" it might be better to have "A < B and B < C". Particularly if B and C are complicated expressions.
Please recall that chained comparisons such are
A < B < C
is to produce simple code when B is not an identifier, but an expression.
For example
low < len(x) < high
or
inner ** 2 < x**2 + y**2 + z**2 < outer**2
which determines if (x, y, z) is in a spherical shell.
Even in those cases, each individual expression could be stored in a variable before doing the comparison:
a, b, c = inner ** 2, x**2 + y**2 + z**2, outer**2 a < b and b < c
But then again I don't find the rich boolean comparison operators (<, <=,
, =>, ==, !=) to be an issue when they're chained together on standard
numeric types such as the above example, particularly when it's the same operator. IMO, it only becomes difficult to read when the operators start to become "mixed up"; more so when the objects are not the builtin types and have overridden operators:
a is b < c in d
Not only do you have to sort out what is happening logically with the operators, you also have to figure out what those operators actually do for that particular object. Whether or not that is "readable" might be somewhat subjective though.
But I think we're probably veering a bit off topic here, the main focus of this thread is on whether or not "A in B < C" should be permissible syntax. Although I'm not a fan of the syntax, I don't think it would be worthwhile for it to raise a SyntaxError for the reasons I mentioned previously. This seems to be something to either enforce in a linter or manually revise in a code review process, rather than through the language itself.
-
Jonathan Fine -
Kyle Stanley