-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
bpo-40334: Support CO_FUTURE_BARRY_AS_BDFL in the new parser #19721
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
Conversation
507de06 to
275201f
Compare
|
Most of the code is threading down the flags to the parser (commit |
275201f to
c970217
Compare
|
Is this needed for alpha 6? |
Nop |
gvanrossum
left a comment
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.
Thanks for all the work here for threading through the flags! I think that might solve one of my problems with type comments.
Parser/pegen/pegen.c
Outdated
| } | ||
|
|
||
| int | ||
| _PyPegen_check_barry_as_flufl(Parser *p){ |
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.
PEP 7
| _PyPegen_check_barry_as_flufl(Parser *p){ | |
| _PyPegen_check_barry_as_flufl(Parser *p) { |
Also this function could use a comment explaining what it returns. Apparently nonzero is an error, meaning either <> detected in Guido mode or != detected in Barry mode, so zero means "okay", except it also could mean "exception". (I guess some later check will eventually detect the exception.)
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.
(I guess some later check will eventually detect the exception.)
In the exception path, we can return anything IIRC because upstream code will catch that and propagate it. The return value is only used to signal if the subrule for the token should return NULL or the token (indicating that it parses).
Maybe is best to always return an error (0) even after the raise.
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.
Note that 0 is not an error here, it's success. (All this is confused by using strcmp(), which returns 0 for equality.) What happens if you return -1 for errors?
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.
Maybe is best to always return an error (0) even after the raise.
Sorry, this should have been: "return an error (nonzero) even after the raise"
What happens if you return -1 for errors?
The parser reports an error because the sub-rule will return NULL for the token
Co-Authored-By: Guido van Rossum <[email protected]>
gvanrossum
left a comment
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.
Go ahead, maybe we'll make the alpha yet!
Closes: we-like-parsers#113
https://bugs.python.org/issue40334