]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.12] gh-115528: Update language reference for PEP 646 (GH-121181) (#124633)
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Thu, 26 Sep 2024 20:03:28 +0000 (22:03 +0200)
committerGitHub <noreply@github.com>
Thu, 26 Sep 2024 20:03:28 +0000 (13:03 -0700)
commitc6f3f83d8889abab430718d40a6f219ff019f737
tree2d8a8cff249d6c9715f10a6d2efe4e68948dda5c
parent27890edd5aa1b990b7f458bcc6c86e83fdd1aaac
[3.12] gh-115528: Update language reference for PEP 646 (GH-121181) (#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 7d3497f617edf77cb6ead6f5e62bce98d77b9ab8)

Co-authored-by: Matthew Rahtz <matthew.rahtz@gmail.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Doc/reference/compound_stmts.rst
Doc/reference/expressions.rst