bpo-40334: Support type comments#19780
Conversation
This does not yet support the "long form" for arguments with type comments. We also totally skip `# type: ignore` comments, and there is no support for func_type_input yet.
This involved a complete refactor of the part of the grammar used to recognise formal parameters in function definitions. I renamed many of the rules involved. The rewrite always includes the comma following a parameter in that argument, so that we can also include the type comment, if any (which follows the comma). The final parameter may not be followed by a comma, so we allow the comma to be omitted, but only if a close parenthesis follows instead (preceded by the type comment, if any). Some additional complications are needed because the code generator doesn't actually support alternatives that may be empty. PS. I didn't refactor the corresponding rules for lambdas, since they don't have type comments.
|
Wait, I forgot to un-skip the test for long-form arguments and it segfaults. On it. |
Sorry, something went wrong.
|
Hm... when parsing something as simple as it seems the end column number for |
Sorry, something went wrong.
|
Dang I already have conflicts. Looking... |
Sorry, something went wrong.
lysnikolaou
left a comment
There was a problem hiding this comment.
Thanks for doing this! Apart from all the TYPE_COMMENTS work, I strongly feel that the arguments improvements made a significant difference in readability.
Sorry, something went wrong.
|
It seems there's a failure in |
Sorry, something went wrong.
|
The test_type_comments failure is new, looking now. |
Sorry, something went wrong.
gvanrossum
left a comment
There was a problem hiding this comment.
All your other suggestions will appear in the next commit.
Sorry, something went wrong.
|
Also, all the calls to |
Sorry, something went wrong.
|
To recap, because it might not be clear what my latest reviews are suggesting. I think that the following are needed:
I'd also make |
Sorry, something went wrong.
|
Got it. I'm putting the CHECK_CALL_NULL_ALLOWED call inside NEW_TYPE_COMMENT -- does that make sense? I don't see that pattern used elsewhere. |
Sorry, something went wrong.
lysnikolaou
left a comment
There was a problem hiding this comment.
One last thing and it's good to go.
Sorry, something went wrong.
|
@lysnikolaou Thank you so much for all your help on this one! It's been invaluable. |
Sorry, something went wrong.
lysnikolaou
left a comment
There was a problem hiding this comment.
My pleasure!
Sorry, something went wrong.
|
Currently working on support for |
Sorry, something went wrong.
|
This doesn't seem to be able to handle function type comments where there aren't "normal" argument types preceding the *args and **kwargs types. I've opened #19894 with a fix, but it's my first time working with CPython's grammar, so apologies in advance for any crimes against parsers committed. |
Sorry, something went wrong.
This implements full support for
# type: <type>comments,# type: ignore <stuff>comments, and thefunc_typeparsing mode forast.parse()andcompile().Closes we-like-parsers#95
https://bugs.python.org/issue40334