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

PEP 646: Be more explicit about grammar changes needed #1880

Merged
merged 6 commits into from
Mar 31, 2021
Merged

PEP 646: Be more explicit about grammar changes needed #1880

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4c1aa36
PEP 646: Be more explicit about grammar changes needed, now that PEP …
mrahtz Mar 20, 2021
ada37b3
PEP 646: Fix quote typo
mrahtz Mar 20, 2021
600bb63
PEP 646: Fix another quotes typo
mrahtz Mar 20, 2021
3d39010
PEP 646: Clarify what star operator would do at runtime
mrahtz Mar 20, 2021
efb3cb2
PEP 646: Clarify that Tuple[T1, *Ts, T2] would also be valid
mrahtz Mar 27, 2021
5a797b4
Clarify context for `*args: *Ts`
gvanrossum Mar 31, 2021
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
20 changes: 15 additions & 5 deletions pep-0646.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -134,6 +134,10 @@ Specification

In order to support the above use cases, we introduce ``TypeVarTuple``. This serves as a placeholder not for a single type but for an *arbitrary* number of types, and behaving like a number of ``TypeVar`` instances packed in a ``Tuple``.

In addition, we introduce a new use for the star operator: to 'unpack'
``TypeVarTuple`` instances, in order to access the type variables
contained in the tuple.

Type Variable Tuples
--------------------

Expand Down Expand Up @@ -683,11 +687,17 @@ these type annotations.
Backwards Compatibility
=======================

The grammar changes necessary for unpacking of type variable tuples using
the star operator are almost all covered by PEP 637. The one exception
is '``*args: *Ts``', which would require an additional change. (This
change could be avoided by simply mandating this be written
as ``Unpack[Ts]``, however.)
In order to use the star operator for unpacking of ``TypeVarTuple`` instances,
we would need to make two grammar changes:

1. Star expressions must be made valid in index operations,
e.g. ``Tuple[*Ts]`` (but *not* in slice operations in general - e.g.
``Tuple[*Ts:*Ts]`` is nonsensical and should remain invalid).
Copy link
Member

Choose a reason for hiding this comment

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

Also clarify that Tuple[x, *y, z] is supported.

we probably need to clarify that this syntax would be accepted anywhere, with semantics as described in PEP 637 (there are subtle edge cases that were reasoned through for PEP 637).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What kinds of place do you have in mind when you say "accepted anywhere"? Aren't starred expressions still only valid in the context of indexing in PEP 637?

In terms of "subtle edge cases" - I see there are these examples in PEP 637:

obj[*()]
obj[*(x,)]
obj[*(x,),]

Are these the ones you had in mind?

More generally, I'm started to wonder whether it would be better to do a from-scratch implementation of PEP 646 in CPython (rather than basing it on the PEP 637 implementation) ato get a better sense of exactly what would be required. Do you think this would be worth it - would this make a big difference to the SC? Or would it be better to get the SC's early opinion before spending time on implementation?

2. We would need to make '``*args: *Ts``' valid.
gvanrossum marked this conversation as resolved.
Show resolved Hide resolved
gvanrossum marked this conversation as resolved.
Show resolved Hide resolved

If these grammar changes are considered too burdensome, we could instead
simply use ``Unpack`` - though in this case it might be better for us to
first decide whether there's a better option.

The ``Unpack`` version of the PEP should be back-portable to previous
versions of Python.
Expand Down