-
-
Notifications
You must be signed in to change notification settings - Fork 54
[2.7, 3.5] Support the per-argument function comment syntax #5
Changes from 2 commits
8325e39
3aa01a1
4c8a2ec
314d17d
97915b0
78206fc
87e46fb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -30,9 +30,10 @@ async_funcdef: ASYNC funcdef | |
funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT] suite | ||
|
||
parameters: '(' [typedargslist] ')' | ||
typedargslist: (tfpdef ['=' test] (',' tfpdef ['=' test])* [',' | ||
['*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef]] | ||
| '*' [tfpdef] (',' tfpdef ['=' test])* [',' '**' tfpdef] | '**' tfpdef) | ||
typedargslist: (tfpdef ['=' test] (',' [TYPE_COMMENT] tfpdef ['=' test])* [',' [TYPE_COMMENT] | ||
['*' [tfpdef] (',' [TYPE_COMMENT] tfpdef ['=' test])* [',' [TYPE_COMMENT] '**' tfpdef] | '**' tfpdef]] [TYPE_COMMENT] | ||
| '*' [tfpdef] (',' [TYPE_COMMENT] tfpdef ['=' test])* [',' [TYPE_COMMENT] '**' tfpdef] [TYPE_COMMENT] | ||
| '**' tfpdef [TYPE_COMMENT]) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One consequence of this definition is that the type comment is required to come after the comma, if any, that follows the argument. This seems fine to me -- thanks to Python's graceful handling of a redundant trailing comma, there's rarely a good reason to want to put the comma on the next line, in a form like this:
such as might appear in other languages for the sake of uniformity between lines and avoiding unnecessary diff noise. It's not clearly specified by PEP 484, though: So we should say this clearly someplace like the README, and also update the PEP to clarify. (And once that's done, can take this point out of the README.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. (Looks like this and the other PEP clarification are still open.) |
||
tfpdef: NAME [':' test] | ||
varargslist: (vfpdef ['=' test] (',' vfpdef ['=' test])* [',' | ||
['*' [vfpdef] (',' vfpdef ['=' test])* [',' '**' vfpdef] | '**' vfpdef]] | ||
|
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.
All this logic looks sensible.
I'd like to have a comment somewhere describing the intended semantics of this
type_comment
sequence -- something like that it's eitherNULL
, or has one entry for each parameter including one for varargs and one for kwargs if applicable, any of which may beNULL
for an absent type 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.
Agreed. Added!