◐ Shell
reader mode source ↗
Skip to content

bpo-40334: Support type comments#19780

Merged
gvanrossum merged 12 commits into
masterfrom
type-comments
Apr 30, 2020
Merged

bpo-40334: Support type comments#19780
gvanrossum merged 12 commits into
masterfrom
type-comments

Conversation

@gvanrossum

@gvanrossum gvanrossum commented Apr 29, 2020

Copy link
Copy Markdown
Member

This implements full support for # type: <type> comments, # type: ignore <stuff> comments, and the func_type parsing mode for ast.parse() and compile().

Closes we-like-parsers#95

https://bugs.python.org/issue40334

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.
@gvanrossum gvanrossum requested a review from pablogsal as a code owner April 29, 2020 00:18
@gvanrossum gvanrossum marked this pull request as draft April 29, 2020 00:18
@gvanrossum gvanrossum changed the title bpo-40334: Support type comments Apr 29, 2020
@gvanrossum

Copy link
Copy Markdown
Member Author

Wait, I forgot to un-skip the test for long-form arguments and it segfaults. On it.

@gvanrossum gvanrossum changed the title bpo-40334: Support type comments [WIP] Apr 29, 2020
@gvanrossum

Copy link
Copy Markdown
Member Author

Hm... when parsing something as simple as

def f(a): pass

it seems the end column number for a is two characters too far. I'll investigate tomorrow.

@gvanrossum gvanrossum marked this pull request as ready for review April 29, 2020 16:00
@gvanrossum

Copy link
Copy Markdown
Member Author

Dang I already have conflicts. Looking...

@gvanrossum gvanrossum requested a review from lysnikolaou April 29, 2020 17:05

@lysnikolaou lysnikolaou left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide 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.

@lysnikolaou

Copy link
Copy Markdown
Member

It seems there's a failure in test_type_comments. Was it there before as well?

@gvanrossum

Copy link
Copy Markdown
Member Author

The test_type_comments failure is new, looking now.

@gvanrossum gvanrossum left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide comment

All your other suggestions will appear in the next commit.

@lysnikolaou

Copy link
Copy Markdown
Member

Also, all the calls to NEW_TYPE_COMMENT should be wrapped with CHECK_CALL_NULL_ALLOWED.

12 hidden items Load more…
@lysnikolaou

lysnikolaou commented Apr 30, 2020

Copy link
Copy Markdown
Member

To recap, because it might not be clear what my latest reviews are suggesting. I think that the following are needed:

  1. Change the type of the tc argument in _PyPegen_add_type_comment_to_arg and _PyPegen_name_default_pair to Token *.
  2. Wrap calls to NEW_TYPE_COMMENT with CHECK_CALL_NULL_ALLOWED.

I'd also make NEW_TYPE_COMMENT an inline function, but this is certainly not needed.

@gvanrossum

Copy link
Copy Markdown
Member Author

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.

@lysnikolaou lysnikolaou left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide comment

One last thing and it's good to go.

@gvanrossum

Copy link
Copy Markdown
Member Author

@lysnikolaou Thank you so much for all your help on this one! It's been invaluable.

@lysnikolaou lysnikolaou left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hide comment

My pleasure!

@gvanrossum gvanrossum merged commit c001c09 into master Apr 30, 2020
@gvanrossum gvanrossum deleted the type-comments branch April 30, 2020 19:12
@lysnikolaou

lysnikolaou commented May 1, 2020

Copy link
Copy Markdown
Member

Currently working on support for feature_version and I just realised that there is no assignment to tok->type_comments in _PyPegen_run_parser_from_file_pointer like the one in _PyPegen_run_parser_from_file_pointer. Is this okay or should it be fixed?

@gvanrossum

Copy link
Copy Markdown
Member Author

Oops. Fixing in #19828

@hauntsaninja

Copy link
Copy Markdown
Contributor

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.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Supporting type_comments=True

5 participants