python / python/cpython

Keyword typo suggestions differ between file and string tokenizers

Open
#156,047 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

3.14 3.15 3.16 interpreter-core topic-parser type-bug
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

Bug report

Bug description:

Keyword-typo SyntaxError suggestions depend on whether CPython processes the same source using the file tokenizer or the string tokenizer.

Create t.py containing:

a=b=c=d=e=f=g=h=i=0
def fn():
    retrun True

Running the file directly:

$ python t.py

uses the file-tokenizer path and produces the helpful diagnostic:

  File ".../t.py", line 3
    retrun True
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'return'?

Running the same file as a module:

$ python -m t

uses the string-tokenizer path and produces:

  File ".../t.py", line 3
    retrun True
           ^^^^
SyntaxError: invalid syntax

The same discrepancy is visible in the default PyREPL-based REPL.

Pasting the complete block as one input:

a=b=c=d=e=f=g=h=i=0
def fn():
    retrun True

produces the generic error:

  File "<python-input-0>", line 3
    retrun True
           ^^^^
SyntaxError: invalid syntax

Entering and submitting the assignment separately, followed by the function:

a=b=c=d=e=f=g=h=i=0
def fn():
    retrun True

produces:

  File "<python-input-2>", line 2
    retrun True
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'return'?

I would expect the same source code to produce the same keyword suggestion regardless of whether it is:

  • executed as a file with python t.py;
  • loaded as a module with python -m t;
  • pasted into PyREPL as one block; or
  • entered into PyREPL statement by statement.

This appears related to the keyword-typo suggestions added in #132449.

traceback.TracebackException._find_keyword_typos() treats the two source paths differently:

  • When the source is loaded from the filename, tokens outside the reported error line are skipped before consuming the token-search budget.
  • When the source is included directly in the SyntaxError metadata, all non-keyword NAME tokens in the extracted source fragment consume that budget.

The search is limited to ten such tokens. In this example, a through i account for nine tokens and fn is the tenth, so the string-source path stops before examining retrun. The file-source path skips those earlier lines and finds the typo.

One possible approach would be to prioritize tokens on the reported error line for both source paths, and only then search the surrounding source fragment. That would preserve the existing work limit while avoiding this tokenizer-dependent result.

CPython versions tested on:

CPython main branch, 3.15, 3.14

Operating systems tested on:

macOS

Linked PRs
  • gh-156087

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at traceback.TracebackException._find_keyword_typos(), comparing its filename and SyntaxError-metadata paths and the ten-token budget described here. Reproduce the four execution modes above; done means the same source produces the same keyword suggestion across file execution, module loading, and both PyREPL input forms.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
compilers
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.