gh-69919: Raise SyntaxError for all invalid sources in compile() - #157586
Open
serhiy-storchaka wants to merge 3 commits into
Open
serhiy-storchaka wants to merge 3 commits into
serhiy-storchaka wants to merge 3 commits into
Conversation
compile(), exec(), eval() and ast.parse() now raise SyntaxError instead of ValueError if the source string contains surrogate characters, and instead of MemoryError or RecursionError if the source is too complex to parse or compile. Consumers that handle SyntaxError, like the code module and IDLE, no longer need to handle those exceptions. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
serhiy-storchaka
requested review from
Eclips4,
ericsnowcurrently,
iritkatriel,
lysnikolaou,
markshannon,
pablogsal and
tomasr8
as code owners
September 15, 2026 19:32
Member
Author
|
@pablogsal @lysnikolaou This and #157585 are alternatives for the same problem; I would like your opinion on which to take. This one changes the exceptions raised by |
Documentation build overview
5 files changed ·
|
A line longer than 2**31 bytes, more than 2**31 lines, or a string literal longer than 2**31 bytes are syntax errors too. Drop the stale mentions of OverflowError and ValueError for invalid literals in the code and codeop documentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
compile(),exec(),eval()andast.parse()now raiseSyntaxErrorinstead ofValueError(UnicodeEncodeError) if the source string contains surrogate characters — with the line, column and text of the offending character, like other syntax errors — instead ofMemoryError("Parser stack overflowed") orRecursionError("Stack overflow during compilation") if the source is too complex to parse or compile, and instead ofOverflowErrorif the source is too large (a line or string literal longer than 231 bytes, or more than 231 lines; verified manually, no tests at that size). This matches how null bytes and undecodable sources are already reported, and means consumers that handleSyntaxError—code.InteractiveInterpreter, the REPL, IDLE — need nothing else: IDLE's Shell no longer gets stuck after such input.Compiling an AST object is unchanged: a cyclic or too deep tree still raises
RecursionError, and an out-of-rangelinenostill raisesOverflowError.The
codeandcodeopdocumentation no longer mentionOverflowErrorandValueError"for an invalid literal": that described Python 1.5/2.0 behavior (integer literals too large for a C long, bad escapes in string literals), which has been aSyntaxErrorsince Python 2.4/3.0.This is an alternative to #157585, which instead makes the consumers catch all exceptions and can be backported.
🤖 Generated with Claude Code