New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SyntaxWarning for 'is <literal>' #87317
Comments
>>> x = 'a'
>>> x is 'a'
True
>>> if x is 'a':
print(x) SyntaxError: "is" with a literal. Did you mean "=="? How come? |
This was a very intentional change from the commit 3bcbedc It's not safe to check This is documented here: In a python REPL, I believe SyntaxWarnings are by default promoted to SyntaxErrors. But when running a file with $ python -Wa ./a.py
.../a.py:2: SyntaxWarning: "is" with a literal. Did you mean "=="?
if x is 'a':
a |
As Dennis says, this is an intentional behavior and will help you avoid bugs. |
Thank you for your responses. I understand the difference between == At 12:49 AM 2/7/2021, Raymond Hettinger wrote:
|
Gary, I cannot replicate that inconsistency in 3.9.0. >>> x = "abc"
>>> x is "abc"
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
True
>>> if x is "abc": pass
...
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="? I don't believe that you should be getting a SyntaxError at all, and both cases should give the same warning. Can you double-check your code, and if you confirm that they give a different result or a SyntaxError, let us know here. Otherwise Raymond and Dennis are correct: this is working correctly. |
There may be reason to re-open this. With Python 3.9.0, I see the inconsistent behavior that Gary describes only when using IDLE. So this is likely an IDLE issue. I attached a screenshot of the difference. |
I think the strangeness is happening because sometimes, the warning is printed to stderr, while other times, IDLE's parser notices the "is <literal>" anti-pattern and raises a SyntaxError. See the attached screenshot for the IDLE output versus the console output for a recent 3.10 build. |
I noticed it in IDLE 3.8. I installed 3.8 because it is a fairly At 03:41 AM 2/7/2021, you wrote:
|
Terry, this may be an IDLE issue, can you confirm whether or not the difference in behaviour is intentional? |
I verified that there are two discrepancies in IDLE versus the standard REPL on Windows with 3.10.0a5. The latter first (which does not converted warnings to errors). Python 3.10.0a4+ (heads/master:0332e569c1, Feb 1 2021, 09:19:58) [MSC v.1900 64 bit (AMD64)] on win32 >>> x = 'a'
>>> x is 'a'
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
True
>>> if x is 'a': print('executed')
...
<stdin>:1: SyntaxWarning: "is" with a literal. Did you mean "=="?
executed versus, with IDLE, >>> x = 'a'
>>> x is 'a' # No warning, also executed.
True
>>> if x is 'a': pass # Error instead of warning, hence not executed.
SyntaxError: "is" with a literal. Did you mean "=="? There is no "IDLE parser" for interactive input. IDLE's Shell uses a subclass of code.InteractiveInterpreter, which calls codeop.CommandCompiler. The latter calls codeop._maybe_compile, which calls compile() 3 times for the source as is, with '\n' appended, and with '\n\n' appended. bpo-40807 fixed the issue of getting 3 warnings instead of 1. For the comparison "x is 'a'", all three compiles emit SyntaxWarning before _maybe_compile returns a code object. The last two warnings are suppressed. IDLE not printing Shell input warnings it is the subject of bpo-37824. Compiling the if statement without a final \n raises I think there is a bug in the revised _maybe_compile but I need to add prints or breakpoints to properly understand it. And have someone locate and explain the REPL C code. If I decide _maybe_compile should be patched, I will open a new issue. --- Also, questions like 'How come?' should better be asked on python-list (or other question-asking forums). Discussion there can lead to specific issues here. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: