GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Wrong error position for tokenizer errors reporting a range if the line contains non-ASCII characters · Issue #156894 · python/cpython

Wrong error position for tokenizer errors reporting a range if the line contains non-ASCII characters #156894

New issue
Copy link
New issue
Copy link
Closed
Closed
Wrong error position for tokenizer errors reporting a range if the line contains non-ASCII characters#156894
Copy link
Labels
3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-parsertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@serhiy-storchaka
serhiy-storchaka
opened on Sep 3, 2026
Issue body actions

The tokenizer errors which report a range point at the wrong characters if the line contains non-ASCII characters before the error.

>>> compile("aaaa = 00010", "<t>", "exec")
  File "<t>", line 1
    aaaa = 00010
           ^^^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers
>>> compile("фффф = 00010", "<t>", "exec")
  File "<t>", line 1
    фффф = 00010
               ^
SyntaxError: leading zeros in decimal integer literals are not permitted; use an 0o prefix for octal integers

Both lines should mark 000; the second one is shifted right by one column per preceding non-ASCII character (offset=8, end_offset=11 versus offset=12, end_offset=15).

The same happens with incompatible string prefixes:

>>> compile("фф = ub'a'", "<t>", "exec")
  File "<t>", line 1
    фф = ub'a'
           ^^
SyntaxError: 'u' and 'b' prefixes are incompatible

SyntaxError.offset and end_offset are character columns, but every caller of _PyTokenizer_syntaxerror_known_range() passes byte offsets:

  • Parser/lexer/number.c:238 — tok->start + 1 - tok->line_start, zeros_end - tok->line_start
  • Parser/lexer/string.c:187 — the same expressions
  • Parser/tokenizer/decoder.c:252 — 0, end_col (only for a BOM-with-cookie line, so ASCII in practice)

_PyTokenizer_syntaxerror() (the -1, -1 case) is not affected: it computes the column by decoding the line prefix with PyUnicode_DecodeUTF8(..., "replace").

The same class of bug was fixed for other errors in gh-102310 and gh-102312; these call sites were missed.

The fix could be either to convert in _syntaxerror_range() with _PyPegen_byte_offset_to_character_offset_raw(), which fixes all callers at once, or to require character offsets from the callers.

Linked PRs

  • gh-156894: Fix the position of syntax errors which cover a range #156901
  • [3.15] gh-156894: Fix the position of syntax errors which cover a range (GH-156901) #156926
  • [3.14] gh-156894: Fix the position of syntax errors which cover a range (GH-156901) #156927
  • [3.13] gh-156894: Fix the position of syntax errors which cover a range (GH-156901) #156928
Reacted by Bartosz Sławecki

Activity

  1. picnixz
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    topic-parser
    on Sep 3, 2026
  2. serhiy-storchaka
    added
    3.13only security fixesonly security fixes
    3.14bugs and security fixesbugs and security fixes
    3.15bugs and security fixesbugs and security fixes
    3.16new features, bugs and security fixesnew features, bugs and security fixes
    on Sep 3, 2026
  3. serhiy-storchaka
    added a commit that references this issue on Sep 4, 2026

    gh-156894: Fix the position of syntax errors which cover a range (GH-…

    59a6913
  4. serhiy-storchaka
    closed this as completedon Sep 4, 2026
  5. serhiy-storchaka
    added 2 commits that reference this issue on Sep 4, 2026

    [3.13] gh-156894: Fix the position of syntax errors which cover a ran…

    e22d4a0

    [3.14] gh-156894: Fix the position of syntax errors which cover a ran…

    113ad29
  6. clin1234
    added a commit that references this issue on Sep 12, 2026

    pythongh-156894: Fix the position of syntax errors which cover a range (

    29a9f7e
  7. pablogsal
    added a commit that references this issue on Sep 24, 2026

    [3.15] gh-156894: Fix the position of syntax errors which cover a ran…

    b4a2366
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.13only security fixesonly security fixes3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesinterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)topic-parsertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.