Should bare logical comparisons raise a warning?
Hi everyone, I've been really impressed by the recent improvements to error messages in Python 3.10. The specific suggestions in some error messages are going to save countless hours of people's time. The benefits for beginners are fairly obvious. But even for experienced programmers, the difference between seeing a missing colon in an error message and just adding it where it should have been vs spending 30 seconds or a minute figuring out what's missing at the start of a loop adds up. One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for one. Here's the simplest example I can come up with: name = 'eric' print(name) name == 'ever' print(name) We want to assign a new value to an existing variable, but we accidentally type a second equals sign. The output here makes the mistake fairly obvious, but in longer programs it can take a while to spot this issue. I know there are some editors and linters that flag this. Is there any reason not to raise a warning or even an error at the language level? Is there any reason to use a bare logical comparison in real-world code?
On 25 Nov 2021, at 13:06, ehmatthes@gmail.com wrote:
Hi everyone,
I've been really impressed by the recent improvements to error messages in Python 3.10. The specific suggestions in some error messages are going to save countless hours of people's time. The benefits for beginners are fairly obvious. But even for experienced programmers, the difference between seeing a missing colon in an error message and just adding it where it should have been vs spending 30 seconds or a minute figuring out what's missing at the start of a loop adds up.
One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for one. Here's the simplest example I can come up with:
name = 'eric' print(name)
name == 'ever'
The __eq__ method is run which might have side effects. Which may mean raising error may be a backwards compat issue, Maybe it is a problem for linters to report as a problem. I have not checked if they already do.
print(name)
We want to assign a new value to an existing variable, but we accidentally type a second equals sign. The output here makes the mistake fairly obvious, but in longer programs it can take a while to spot this issue.
I know there are some editors and linters that flag this. Is there any reason not to raise a warning or even an error at the language level? Is there any reason to use a bare logical comparison in real-world code? _______________________________________________ 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/4QVUWN... Code of Conduct: http://python.org/psf/codeofconduct/
On Thu, Nov 25, 2021 at 9:51 AM Barry
One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for one.
nor have I. However, this strikes me as very much a problem for linters to solve (and some do already). I just tried mine, and it doesn't.
name == 'ever'
I do get a undefined name error in the linter if I do this by itself, but, of course not if name haad been previously defined. However, even from a linter's perspective, I think this is not exactly misuse of "==", b ut rather a amore general "expression not assigned to anything" working. Of course, as Barry pointed out, you might have an unassigned expression in order to get a side effect. But the reason I think it's a linter's job is that I don't think there is any other case where Python tries to warn you about things that are not illegal. Yes, this is one example where it might make sense, but where do we draw the line? -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Wed, Nov 24, 2021 at 07:15:58PM -0000, ehmatthes@gmail.com wrote:
One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for one.
You've never used the interactive interpeter? *wink* You're right, of course, that outside of the REPL it would be very unusual, and quite rare, to use `==` for its side-effects. Another usual use would be to overload the `==` operator for a DSL. They might be rare, but they are allowed, and the Python interpreter doesn't generally raise warnings for legal expressions used as statement just because they *might* be a mistake. Some compilers and interpreters raise a plethora of warnings, or errors, for legal but "weird" code that might be a mistake. But Python's interpreter tends to be a lot more easy-going, assuming you know what you are doing, and leaves it up to third-party linters. IDEs and code checkers to be more opinionated. Personally, I think that this is the right design. People can pick and choose which, if any, linter they use, and how strict they want it to be. But I can also understand that some people might want the interpreter to also have a built-in linter to flag mistakes. -- Steve
On 26/11/2021 00:12, Steven D'Aprano wrote:
On Wed, Nov 24, 2021 at 07:15:58PM -0000, ehmatthes@gmail.com wrote:
One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for one. You've never used the interactive interpeter? *wink* Very good point. You type `1==1`, it tells you `True`.
You're right, of course, that outside of the REPL it would be very unusual, and quite rare, to use `==` for its side-effects. Another usual use would be to overload the `==` operator for a DSL.
They might be rare, but they are allowed, and the Python interpreter doesn't generally raise warnings for legal expressions used as statement just because they *might* be a mistake.
Some compilers and interpreters raise a plethora of warnings, or errors, for legal but "weird" code that might be a mistake. But Python's interpreter tends to be a lot more easy-going, assuming you know what you are doing, and leaves it up to third-party linters. IDEs and code checkers to be more opinionated.
Personally, I think that this is the right design. People can pick and choose which, if any, linter they use, and how strict they want it to be. But I can also understand that some people might want the interpreter to also have a built-in linter to flag mistakes.
+1. This just feels like it has "this is a job for linters" written all over it. YMMV. Best wishes Rob Cliffe
On Fri, Nov 26, 2021 at 12:02 PM Rob Cliffe via Python-ideas
On 26/11/2021 00:12, Steven D'Aprano wrote:
Personally, I think that this is the right design. People can pick and choose which, if any, linter they use, and how strict they want it to be. But I can also understand that some people might want the interpreter to also have a built-in linter to flag mistakes.
+1. This just feels like it has "this is a job for linters" written all over it. YMMV.
Agreed. Though there are a small number of cases where the language itself offers helpful warnings:
x = 1 x is 2 <stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="? False
but these are reserved for situations that are very definitely, but more subtly, wrong (since this code will often appear to work just fine due to small-int caching). Chrisa
You've never used the interactive interpeter? *wink*
All of the responses here have been really helpful to read, but this line is the clearest. I'm almost certain I have used this syntax in the interpreter, but I spend so much time in editors I forgot about that use case. Thanks for the clarification, and thank you to everyone else in the thread as well. Eric
participants (6)
-
Barry -
Chris Angelico -
Christopher Barker -
ehmatthes＠gmail.com -
Rob Cliffe -
Steven D'Aprano