gh-151303 : Improve `SyntaxError` suggestions for common operator typos and cross-language mistakes by Aniketsy · Pull Request #151375 · python/cpython

Aniketsy · 2026-06-11T17:46:06Z

Issue: Improve SyntaxError suggestions for common operator typos and cross-language mistakes #151303

StanFromIreland · 2026-06-13T09:40:18Z

+    | invalid_eqeqeq

+invalid_diamond_op:
+    | a='<' b='>' { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax.  Maybe you meant '!=' instead of '<>'?") }


Won't this break when __future__.CO_FUTURE_BARRY_AS_BDFL is true?

hmm , yes

aniket@DESKTOP-074O80J:/mnt/d/cpython/cpython$ ./python.exe -c " __futu> from __future__ import barry_as_FLUFL > 1 < > 2 > " File "<string>", line 3 1 < > 2 ^^^ SyntaxError: invalid syntax. Maybe you meant '!=' instead of '<>'?

please let me know your thoughts on this ...

aniket@DESKTOP-074O80J:/mnt/d/cpython/cpython$ git diff Grammar/python.gram diff --git a/Grammar/python.gram b/Grammar/python.gram index 61a6d5ea90..19ef406437 100644 --- a/Grammar/python.gram +++ b/Grammar/python.gram @@ -805,7 +805,11 @@ compare_op_bitwise_or_pair[CmpopExprPair*]: | invalid_eqeqeq invalid_diamond_op: - | a='<' b='>' { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax. Maybe you meant '!=' instead of '<>'?") } + | a='<' b='>' { + (p->flags & PyPARSE_BARRY_AS_BDFL) + ? RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax. Maybe you meant '<>' instead of '< >'?") + : RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax. Maybe you meant '!=' instead of '<>'?") + } eq_bitwise_or[CmpopExprPair*]: '==' a=bitwise_or { _PyPegen_cmpop_expr_pair(p, Eq, a) } invalid_eqeqeq: | a='==' b='=' { RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax. Maybe you meant '==' instead of '==='?") }

output:

aniket@DESKTOP-074O80J:/mnt/d/cpython/cpython$ ./python.exe -c "1 < > 2" File "<string>", line 1 1 < > 2 ^^^ SyntaxError: invalid syntax. Maybe you meant '!=' instead of '<>'?

aniket@DESKTOP-074O80J:/mnt/d/cpython/cpython$ ./python.exe -c " __futu> from __future__ import barry_as_FLUFL > 1 < > 2 > " File "<string>", line 3 1 < > 2 ^^^ SyntaxError: invalid syntax. Maybe you meant '<>' instead of '< >'?

hmm, yes

No, this example doesn't break __future__ import. But I suspect, that __future__.CO_FUTURE_BARRY_AS_BDFL is the reason that your code doesn't work without spaces. This can be "fixed" by this patch:

diff --git a/Tools/build/generate_token.py b/Tools/build/generate_token.py index 9ee5ec86e75..28a0ce1ff78 100755 --- a/Tools/build/generate_token.py +++ b/Tools/build/generate_token.py @@ -178,7 +178,7 @@ def generate_chars_to_token(mapping, n=1): def make_c(infile, outfile='Parser/token.c'): tok_names, ERRORTOKEN, string_to_tok = load_tokens(infile) - string_to_tok['<>'] = string_to_tok['!='] +# string_to_tok['<>'] = string_to_tok['!='] chars_to_token = {} for string, value in string_to_tok.items(): assert 1 <= len(string) <= 3

Look at the difference:

$ cat a.py 1 =! 2 $ cat a.py | ./python -m tokenize 1,0-1,1: NUMBER '1' 1,2-1,3: OP '=' 1,3-1,4: OP '!' 1,5-1,6: NUMBER '2' 1,6-1,7: NEWLINE '\n' 2,0-2,0: ENDMARKER ''

vs

$ cat a.py 1 <> 2 $ cat a.py | ./python -m tokenize 1,0-1,1: NUMBER '1' 1,2-1,4: OP '<>' 1,5-1,6: NUMBER '2' 1,6-1,7: NEWLINE '\n' 2,0-2,0: ENDMARKER ''

Regardless on a joke, it looks as a tokenizer bug. I'll open a separate issue.

thanks for looking into this, i'll revert the changes

No, this example doesn't break future import.

It still does break it, we're suggesting != for < > which is invalid syntax when __future__.CO_FUTURE_BARRY_AS_BDFL is true.

Yes, this is wrong, see my comment below. But nothing to do with __future__.barry_as_FLUFL.

Currently, we have a hidden token (<> is alias for !=) in the grammar. So, this patch will not produce an error without a space between. See #151464.

serhiy-storchaka

Like in the previous PR, check that there is no gap between tokens.

serhiy-storchaka · 2026-06-14T07:46:34Z


+    def test_diamond_operator(self):
+        self._check_error(
+            "1 < > 2",


There should not be space in the middle.

Aniketsy · 2026-06-15T03:47:02Z

@skirpichev thanks for the review, i've updated with helper function

skirpichev · 2026-06-17T08:08:30Z

+        if (strcmp(tok_str, "<>") == 0) {
+            RAISE_SYNTAX_ERROR("invalid syntax.  Are you trying to overthrow the SC?  Use operator \"!=\"!");
+            return -1;
+        }


I would prefer not use this workaround for #151464. Leave "<>" case for another PR.

Should i revert the changes for this case ?

This is my suggestion, yes.

I would prefer not use this workaround for #151464. Leave "<>" case for another PR.

@skirpichev are you planning to work on this PR as issue was assigned to you, or i can open a follow up pr after this . please let me know 😊

Feel free to do this.

I'm waiting for opinion of core developers. Beware that posted patch is only a partial solution. Proper support of this easter egg will require much more work. Do we need this? I'm not sure. Other options:

call this not a bug

remove joke.

I'm waiting for opinion of core developers.

in that case i think i should also wait for the opinion.

Beware that posted patch is only a partial solution. Proper support of this easter egg will require much more work.

and meanwhile, i'll explore this, and will update you in the issue ... Thanks :)

serhiy-storchaka · 2026-06-17T09:00:51Z

We wait for other PR to be merged first.

…e-151303.mzlJxi.rst

serhiy-storchaka · 2026-06-28T05:01:58Z

For future -- never use rebase, amend and force-push. This forces us to review the entire PR from the beginning, instead of just the new changes.

Aniketsy · 2026-06-28T05:29:25Z

For future -- never use rebase, amend and force-push. This forces us to review the entire PR from the beginning, instead of just the new changes.

sorry for creating extra works, i didn't know we can solve conflicts without rebase, i'll keep in mind and i always wanted to never use rebase as i used to mess with this in past and this leads to creating my PR dirty that's the reason i built grebase(https://github.com/Aniketsy/grebase) But now i think i got alternative way to do . Thanks!

Aniketsy · 2026-07-14T13:00:32Z

gentle ping, i've resolved the conflict in parser.c, i think it would be great if we can move forward with this . Thanks :)

skirpichev · 2026-07-29T06:05:53Z

+    def test_diamond_operator(self):
+        self._check_error(
+            "1<>2",
+            "invalid syntax",
+            lineno=1,
+            end_lineno=1,
+            offset=2,
+            end_offset=4,
+        )
+
+    def test_diamond_operator_barry_as_flufl(self):


I think you should remove these tests.

yeah make sense , as we have left this fix for other PR. thanks for pointing , i'll remove

pablogsal · 2026-07-30T14:53:18Z

            "invalid syntax",
            lineno=2,
            end_lineno=2,
            offset=5,


Unless I am missing something, this _check_error lost the end_offset=6 check it had before this PR , looks like an accident from moving the new tests around. Can you restore it?

pablogsal · 2026-07-30T14:53:18Z

+    | invalid_eqeqeq

 eq_bitwise_or[CmpopExprPair*]: '==' a=bitwise_or { _PyPegen_cmpop_expr_pair(p, Eq, a) }
+invalid_eqeqeq:


Nit: we define the invalid_* rules below the START OF INVALID RULES marker (see how invalid_bitwise_and is referenced from bitwise_and but defined there). Can we move invalid_eqeqeq to that section and regenerate?

Can we move invalid_eqeqeq to that section and regenerate?

sure, thanks for pointing out, i'll update

pablogsal · 2026-07-30T14:53:18Z

+invalid_eqeqeq:
+    | a='==' b='=' {
+        _PyPegen_tokens_are_adjacent(a, b)
+        ? RAISE_SYNTAX_ERROR_KNOWN_RANGE(a, b, "invalid syntax.  Maybe you meant 'is' instead of '==='?")


Why are we suggesting is here instead of ==? In JavaScript and PHP === is (strict) equality, so == is what these users almost always mean, and suggesting is can push people into x is 'foo' identity bugs, no?

In JavaScript and PHP === is (strict) equality, so == is what these users almost always mean, and suggesting is can push people into x is 'foo' identity bugs, no?

thanks, this is something interesting 😄 we missed, and make sense (being honest, i got confused for sometime, but yes we should use == )

pablogsal · 2026-07-30T14:53:18Z

@@ -0,0 +1 @@
+Improve :exc:`SyntaxError` messages for common operator typos coming from other languages: ``=<``, ``=>``, and ``=!`` now suggest ``<=``, ``>=``, and ``!=`` respectively, ``===`` suggests ``is``, and ``<>`` shows a tailored message suggesting ``!=``.


The NEWS entry still says that <> shows a tailored message suggesting !=, but that part was reverted , 1<>2 still raises plain invalid syntax and your own test_diamond_operator checks exactly that. Please, update the entry to drop the <> part.

pablogsal · 2026-07-30T14:53:18Z

@@ -0,0 +1 @@
+Improve :exc:`SyntaxError` messages for common operator typos coming from other languages: ``=<``, ``=>``, and ``=!`` now suggest ``<=``, ``>=``, and ``!=`` respectively, ``===`` suggests ``is``, and ``<>`` shows a tailored message suggesting ``!=``.


<> still reports plain invalid syntax; the tailored message was reverted. Can we remove this clause from the NEWS entry?

Can we remove this clause from the NEWS entry?

sure, make sense 👍

pablogsal · 2026-07-30T14:53:18Z

            "'%s' is an illegal expression for augmented assignment",
            _PyPegen_get_expr_name(a)
        )}
+    | star_expressions a='=' b='<' {


These only fire for bare statements, so if a => b: still gives the generic error, no? That is probably fine for a first iteration (the = < tokenization makes it look like an assignment), but maybe we should add a test documenting it or a follow-up issue for the if/while case.

i'll open a follow up issue for this, please let me know if you lean towards adding test i fine with that too

bedevere-app · 2026-07-30T14:53:25Z

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Aniketsy · 2026-07-31T06:07:31Z

I have made the requested changes; please review again .

bedevere-app · 2026-07-31T06:07:38Z

Thanks for making the requested changes!

@pablogsal: please review the changes made to this pull request.

Aniketsy requested review from lysnikolaou and pablogsal as code owners June 11, 2026 17:46

bedevere-app Bot added the awaiting review label Jun 11, 2026

bedevere-app Bot mentioned this pull request Jun 11, 2026

Improve SyntaxError suggestions for common operator typos and cross-language mistakes #151303

Open

This comment was marked as resolved.

Sign in to view

StanFromIreland reviewed Jun 11, 2026

View reviewed changes

Comment thread Grammar/python.gram Outdated

Aniketsy commented Jun 13, 2026

View reviewed changes

Comment thread Misc/NEWS.d/next/Core_and_Builtins/2026-06-12-03-41-39.gh-issue-151303.mzlJxi.rst Outdated

StanFromIreland reviewed Jun 13, 2026

View reviewed changes

skirpichev reviewed Jun 14, 2026

View reviewed changes

Comment thread Grammar/python.gram Outdated

This comment was marked as resolved.

Sign in to view

Aniketsy mentioned this pull request Jun 14, 2026

gh-146495: Improve SyntaxError message for && and || operators #150906

Merged

serhiy-storchaka reviewed Jun 14, 2026

View reviewed changes

skirpichev requested changes Jun 15, 2026

View reviewed changes

bedevere-app Bot added awaiting core review and removed awaiting review labels Jun 15, 2026

skirpichev reviewed Jun 17, 2026

View reviewed changes

skirpichev requested review from StanFromIreland and serhiy-storchaka June 17, 2026 08:11

Aniketsy and others added 10 commits June 27, 2026 18:47

Improve SyntaxError suggestions for common operator typos

c56b1d0

add question mark in the suggestion and tests

a0d9269

update tests

a99fb0b

📜🤖 Added by blurb_it.

4d1a4b7

improve syntaxerror message <> typo

7479668

Update Misc/NEWS.d/next/Core_and_Builtins/2026-06-12-03-41-39.gh-issu…

86d3df7

…e-151303.mzlJxi.rst

improve syntaxerror message <> typo

231949c

Improve SyntaxError suggestions for common operator typos

118dbf2

fix and update tests

148d8b9

add helper function, update tests

7a5f540

revert <> error message, update tests

ef3de3f

Aniketsy force-pushed the fix-151303 branch from d89dfcf to ef3de3f Compare June 27, 2026 19:41

skirpichev approved these changes Jun 28, 2026

View reviewed changes

Aniketsy added 2 commits July 14, 2026 12:35

resolve conflicts

c92b786

regenerate parser.c

b0cad50

skirpichev reviewed Jul 29, 2026

View reviewed changes

pablogsal requested changes Jul 30, 2026

View reviewed changes

bedevere-app Bot removed the awaiting core review label Jul 30, 2026

bedevere-app Bot added the awaiting changes label Jul 30, 2026

address review points, remove tests and update news entry

0fda0cd

bedevere-app Bot added awaiting change review and removed awaiting changes labels Jul 31, 2026

bedevere-app Bot requested a review from pablogsal July 31, 2026 06:07

Aniketsy mentioned this pull request Jul 31, 2026

Extend operator-typo SyntaxError suggestions (=<, =>, =!) to if/while other conditions #154970

Open

		@@ -0,0 +1 @@
		Improve :exc:`SyntaxError` messages for common operator typos coming from other languages: ``=<``, ``=>``, and ``=!`` now suggest ``<=``, ``>=``, and ``!=`` respectively, ``===`` suggests ``is``, and ``<>`` shows a tailored message suggesting ``!=``.

Uh oh!

Uh oh!

Conversation

Aniketsy commented Jun 11, 2026 • edited by bedevere-app Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

StanFromIreland Jun 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment was marked as resolved.

serhiy-storchaka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Aniketsy commented Jun 15, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

serhiy-storchaka commented Jun 17, 2026

Uh oh!

serhiy-storchaka commented Jun 28, 2026

Uh oh!

Aniketsy commented Jun 28, 2026

Uh oh!

Aniketsy commented Jul 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Aniketsy commented Jun 11, 2026 •

edited by bedevere-app Bot

Loading

StanFromIreland Jun 14, 2026 •

edited

Loading