Skip to content
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

Jump to bottom

PEP 646 grammar changes are not documented #115528

Closed
JelleZijlstra opened this issue Feb 15, 2024 · 3 comments · Fixed by python/peps#3832
Closed

PEP 646 grammar changes are not documented #115528

JelleZijlstra opened this issue Feb 15, 2024 · 3 comments · Fixed by python/peps#3832
Labels
docs Documentation in the Doc dir topic-typing

Comments

@JelleZijlstra
Copy link
Member

JelleZijlstra commented Feb 15, 2024 •
edited by bedevere-app bot
Loading

PEP-646 made some changes to the grammar, but neither is reflected in the language reference:

References: python/peps#3671 (making the PEP final); #31018 (implementation of the grammar changes)

Linked PRs
@JelleZijlstra JelleZijlstra added the docs Documentation in the Doc dir label Feb 15, 2024
@hugovk hugovk mentioned this issue Mar 24, 2024
Closed
16 tasks
@hugovk
Copy link
Member

hugovk commented Jun 5, 2024

@mrahtz Hello! Pinging as author of #31018 and co-author of PEP-646.

There's still a bit of work to be done for the PEP: document the changes, and mark the PEP as Final with a link to the docs.

Please could you co-ordinate with your co-authors to finish this off? Thank you!

@mrahtz
Copy link
Contributor

mrahtz commented Jun 7, 2024

Ooh thanks for the heads up! I'll try to get to this in the next week or so.

@bedevere-app bedevere-app bot mentioned this issue Jun 9, 2024
Closed
@mrahtz mrahtz mentioned this issue Jun 9, 2024
Merged
6 tasks
@bedevere-app bedevere-app bot mentioned this issue Jun 30, 2024
Merged
@AlexWaygood AlexWaygood reopened this Jun 30, 2024
JelleZijlstra added a commit that referenced this issue Sep 26, 2024
@mrahtz @JelleZijlstra
gh-115528: Update language reference for PEP 646 (#121181)
7d3497f 
To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.

What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)

    Generic[x]
    Generic[*x]
    Generic[*x, y]
    Generic[y, *x]
    Generic[x := 1]
    Generic[x := 1, y := 2]

So introducting

    flexible_expression: expression | assignment_expression | starred_item

end then switching `subscription` to use `flexible_expression` sorts that.

But then we need to field `yield` - for which any of the following are
apparently valid:

    yield x
    yield x,
    yield x, y
    yield *x,
    yield *x, *y

Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.



Co-authored-by: Jelle Zijlstra <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Sep 26, 2024
@mrahtz @JelleZijlstra @miss-islington
pythongh-115528: Update language reference for PEP 646 (pythonGH-121181)
e518172 
To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.

What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)

    Generic[x]
    Generic[*x]
    Generic[*x, y]
    Generic[y, *x]
    Generic[x := 1]
    Generic[x := 1, y := 2]

So introducting

    flexible_expression: expression | assignment_expression | starred_item

end then switching `subscription` to use `flexible_expression` sorts that.

But then we need to field `yield` - for which any of the following are
apparently valid:

    yield x
    yield x,
    yield x, y
    yield *x,
    yield *x, *y

Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.

(cherry picked from commit 7d3497f)

Co-authored-by: Matthew Rahtz <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Sep 26, 2024
@mrahtz @JelleZijlstra @miss-islington
pythongh-115528: Update language reference for PEP 646 (pythonGH-121181)
e2c34d5 
To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.

What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)

    Generic[x]
    Generic[*x]
    Generic[*x, y]
    Generic[y, *x]
    Generic[x := 1]
    Generic[x := 1, y := 2]

So introducting

    flexible_expression: expression | assignment_expression | starred_item

end then switching `subscription` to use `flexible_expression` sorts that.

But then we need to field `yield` - for which any of the following are
apparently valid:

    yield x
    yield x,
    yield x, y
    yield *x,
    yield *x, *y

Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.

(cherry picked from commit 7d3497f)

Co-authored-by: Matthew Rahtz <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
This was referenced Sep 26, 2024
Merged
Merged
AlexWaygood pushed a commit that referenced this issue Sep 26, 2024
@miss-islington @mrahtz @JelleZijlstra
[3.12] gh-115528: Update language reference for PEP 646 (GH-121181) (#…
c6f3f83 
…124633)

gh-115528: Update language reference for PEP 646 (GH-121181)

To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.

What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)

    Generic[x]
    Generic[*x]
    Generic[*x, y]
    Generic[y, *x]
    Generic[x := 1]
    Generic[x := 1, y := 2]

So introducting

    flexible_expression: expression | assignment_expression | starred_item

end then switching `subscription` to use `flexible_expression` sorts that.

But then we need to field `yield` - for which any of the following are
apparently valid:

    yield x
    yield x,
    yield x, y
    yield *x,
    yield *x, *y

Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.

(cherry picked from commit 7d3497f)

Co-authored-by: Matthew Rahtz <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Yhg1s pushed a commit that referenced this issue Sep 26, 2024
@miss-islington @mrahtz @JelleZijlstra
[3.13] gh-115528: Update language reference for PEP 646 (GH-121181) (#…
410e0ef 
…124632)

gh-115528: Update language reference for PEP 646 (GH-121181)

To recap: the objective is to make starred expressions valid in `subscription`,
which is used for generics: `Generic[...]`, `list[...]`, etc.

What _is_ gramatically valid in such contexts? Seemingly any of the following.
(At least, none of the following throw `SyntaxError` in a 3.12.3 REPL.)

    Generic[x]
    Generic[*x]
    Generic[*x, y]
    Generic[y, *x]
    Generic[x := 1]
    Generic[x := 1, y := 2]

So introducting

    flexible_expression: expression | assignment_expression | starred_item

end then switching `subscription` to use `flexible_expression` sorts that.

But then we need to field `yield` - for which any of the following are
apparently valid:

    yield x
    yield x,
    yield x, y
    yield *x,
    yield *x, *y

Introducing a separate `yield_list` is the simplest way I've been figure out to
do this - separating out the special case of `starred_item ,`.

(cherry picked from commit 7d3497f)

Co-authored-by: Matthew Rahtz <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
@AlexWaygood
Copy link
Member

I think we're done here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
docs Documentation in the Doc dir topic-typing
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

PEP 646: Mark Final mrahtz/peps
4 participants
@JelleZijlstra @hugovk @mrahtz @AlexWaygood