Skip to content

bpo-43224: Draft implementation of PEP 646 #30398

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.

Sign up for GitHub

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

Closed
mrahtz wants to merge 18 commits into from
Closed

bpo-43224: Draft implementation of PEP 646 #30398

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
18 commits
Select commit Hold shift + click to select a range
64abc0a
PEP 646: Grammar and compiler changes
mrahtz Dec 3, 2021
b725671
PEP 646: Add tests for syntax changes
mrahtz Jan 3, 2022
ea329b9
PEP 646: Add AST tests for *args annotations
mrahtz Dec 7, 2021
681dc4e
PEP 646: Add AST tests for return types with unpacking
mrahtz Dec 7, 2021
69f575f
PEP 646: Add AST tests for variable annotations with unpacking
mrahtz Dec 7, 2021
095a620
PEP 646: Add support for starring tuple types
mrahtz Jan 2, 2022
6713748
PEP 646: Add tests for starring tuple types
mrahtz Jan 2, 2022
038b8f0
PEP 646: Implement support in typing.py
mrahtz Jan 2, 2022
f028339
PEP 646: Add tests for everything in typing.py
mrahtz Jan 2, 2022
38c17d3
PEP 646: Add tests for typing.get_{origin,args}
mrahtz Jan 4, 2022
9991937
PEP 646: Various fixes to genericaliasobject.c
mrahtz Jan 15, 2022
9017d22
PEP 646: Fix test_pep646_syntax import
mrahtz Jan 15, 2022
07ed599
PEP 646: Add docstring for TypeVarTuple
mrahtz Jan 17, 2022
74e5252
PEP 646: Swap a Py_INCREF with a Py_NewRef
mrahtz Jan 20, 2022
6cb3aa5
PEP 646: Add test for assigning to a slice containing a star
mrahtz Jan 20, 2022
daef59b
📜🤖 Added by blurb_it.
blurb-it[bot] Jan 20, 2022
3c2a7e7
PEP 646: Add line to Doc/whatsnew
mrahtz Jan 20, 2022
456156a
PEP 646: Use stdbool.h; separate test cases
mrahtz Jan 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
PEP 646: Grammar and compiler changes
  • Loading branch information
@mrahtz
mrahtz committed Jan 2, 2022
commit 64abc0ad5202e368a6b00d941a08bf64590da257
9 changes: 8 additions & 1 deletion Grammar/python.gram
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -308,6 +308,8 @@ slash_with_default[SlashWithDefault*]:
star_etc[StarEtc*]:
| '*' a=param_no_default b=param_maybe_default* c=[kwds] {
_PyPegen_star_etc(p, a, b, c) }
| '*' a=param_no_default_star_annotation b=param_maybe_default* c=[kwds] {
_PyPegen_star_etc(p, a, b, c) }
| '*' ',' b=param_maybe_default+ c=[kwds] {
_PyPegen_star_etc(p, NULL, b, c) }
| a=kwds { _PyPegen_star_etc(p, NULL, NULL, a) }
Expand All @@ -331,14 +333,19 @@ kwds[arg_ty]: '**' a=param_no_default { a }
param_no_default[arg_ty]:
| a=param ',' tc=TYPE_COMMENT? { _PyPegen_add_type_comment_to_arg(p, a, tc) }
| a=param tc=TYPE_COMMENT? &')' { _PyPegen_add_type_comment_to_arg(p, a, tc) }
param_no_default_star_annotation[arg_ty]:
Copy link
Copy Markdown
Member

@pablogsal pablogsal Jan 10, 2022

Choose a reason for hiding this comment

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

Why not join these to param_no_default? That way we can remove the extra rule in star_etc.

Copy link
Copy Markdown
Contributor Author

@mrahtz mrahtz Jan 15, 2022

Choose a reason for hiding this comment

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

Hmm, wouldn't that mess with other things that use param_no_default though? E.g. kwds uses param_no_default, so if we joined these to param_no_default, wouldn't we accidentally allow def foo(***args)?

Copy link
Copy Markdown
Contributor Author

@mrahtz mrahtz Jan 25, 2022

Choose a reason for hiding this comment

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

Friendly poke :)

| a=param_star_annotation ',' tc=TYPE_COMMENT? { _PyPegen_add_type_comment_to_arg(p, a, tc) }
| a=param_star_annotation tc=TYPE_COMMENT? &')' { _PyPegen_add_type_comment_to_arg(p, a, tc) }
param_with_default[NameDefaultPair*]:
| a=param c=default ',' tc=TYPE_COMMENT? { _PyPegen_name_default_pair(p, a, c, tc) }
| a=param c=default tc=TYPE_COMMENT? &')' { _PyPegen_name_default_pair(p, a, c, tc) }
param_maybe_default[NameDefaultPair*]:
| a=param c=default? ',' tc=TYPE_COMMENT? { _PyPegen_name_default_pair(p, a, c, tc) }
| a=param c=default? tc=TYPE_COMMENT? &')' { _PyPegen_name_default_pair(p, a, c, tc) }
param[arg_ty]: a=NAME b=annotation? { _PyAST_arg(a->v.Name.id, b, NULL, EXTRA) }
param_star_annotation[arg_ty]: a=NAME b=star_annotation { _PyAST_arg(a->v.Name.id, b, NULL, EXTRA) }
annotation[expr_ty]: ':' a=expression { a }
star_annotation[expr_ty]: ':' a=star_expression { a }
default[expr_ty]: '=' a=expression { a }

# If statement
Expand Down Expand Up @@ -780,7 +787,7 @@ primary[expr_ty]:

slices[expr_ty]:
| a=slice !',' { a }
| a[asdl_expr_seq*]=','.slice+ [','] { _PyAST_Tuple(a, Load, EXTRA) }
| a[asdl_expr_seq*]=','.(slice | starred_expression)+ [','] { _PyAST_Tuple(a, Load, EXTRA) }
Copy link
Copy Markdown
Member

@pablogsal pablogsal Jan 10, 2022

Choose a reason for hiding this comment

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

I would prefer to move starred_expression as another option of slice as we already have named_expression there

Copy link
Copy Markdown
Contributor Author

@mrahtz mrahtz Jan 15, 2022

Choose a reason for hiding this comment

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

I just tried this, but then I get SyntaxError: can't use starred expression here for e.g. a[*b].

I think what happens is, if we move starred_expression to slice (as | a=starred_expression { a }), then when we do a[*b], it triggers the first option of slices, where the starred_expression doesn't get processed by _PyAST_Tuple.

I can't see any way to make sure _PyAST_Tuple definitely gets called for starred_expression without doing something to slices, so I think the original attempt with (slice | starred_expression) is cleanest. Wdyt?


slice[expr_ty]:
| a=[expression] ':' b=[expression] c=[':' d=[expression] { d }] { _PyAST_Slice(a, b, c, EXTRA) }
Expand Down
Loading