-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
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
gh-113744: Add a new IncompleteInputError exception to improve incomplete input detection in the codeop module #113745
Conversation
pablogsal
commented
Jan 5, 2024
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Formalize incomplete error exceptions to improve codeop module handling #113744
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Something needs to be regenerated.
…incomplete input detection in the codeop module Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I am not sure about the name. On one hand, it looks correct and I do not have anything better, on other hand, it can be confused with the use case for BlockingIOError. In future we can see misuse of this error in cases not related to parsing Python sources. Not sure if it's something to worry about.
I don't think we should worry about it because it's not user facing (at least for now). It's used internally in a special mode of the parser that's also not user facing. And in the rare case where a user encounters it it's relatively easy to identify why is appearing. |
…mprove incomplete input detection in the codeop module Signed-off-by: Pablo Galindo <pablogsal@gmail.com>
Let's not add it to the stable ABI, then? |
Sorry @encukou but seems that the auto-land landed it before I could tackle your comment. Do you want to remove it from the stable ABI? The name is public in any case so it would be weird if is not there but you can invoke it from builtins |
If it is used internally in a special mode of the parser, it could be not added to buildins. But I do not see how this mode is special. It does not use any magic flags or private arguments. I expect it to be used in many third-party REPL implementations. And maybe even in the C code. So it is okay to make it as public as other SyntaxError subclasses. |
Adding it to the public C API (and especially to the stable ABI) means that it is user facing, and now is the time to worry about the name. TBH, the name is fine with me. |
…incomplete input detection in the codeop module (python#113745) Signed-off-by: Pablo Galindo <pablogsal@gmail.com>