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.

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: Add additional motivation for why *Ts over Unpack[Ts] #2054

Merged
merged 2 commits into from
Aug 23, 2021
Merged
Changes from 1 commit
Commits
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
45 changes: 31 additions & 14 deletions pep-0646.rst
Original file line number Diff line number Diff line change
@@ -740,8 +740,8 @@ This PEP requires two grammar changes. Full diffs of ``python.gram``
and simple tests to confirm correct behaviour are available at
https://github.com/mrahtz/cpython/commits/pep646-grammar.

Star expressions in indexes
---------------------------
Change 1: Star Expressions in Indexes
-------------------------------------

The first grammar change enables use of star expressions in index operations (that is,
within square brackets), necessary to support star-unpacking of TypeVarTuples:
@@ -844,8 +844,8 @@ However, note that slices involving starred expressions are still invalid:
array[*idxs_start:*idxs_end]


``*args`` as a TypeVarTuple
---------------------------
Change 2: ``*args`` as a TypeVarTuple
-------------------------------------

The second change enables use of ``*args: *Ts`` in function definitions.

@@ -922,16 +922,33 @@ annotation is possible:
Again, prevention of such annotations will need to be done by, say, static
checkers, rather than at the level of syntax.

Alternatives
------------

If these two grammar changes are considered too burdensome, there are two alternatives:

1. **Support change 1 but not change 2**. Starred expressions within indexes are
more important to us than the ability to annotation ``*args``.
2. **Use ``Unpack`` instead** - though in this case it might be better for us to
reconsider our options to see whether there isn't another option which would be
more readable.
Alternatives (Why Not Just Use ``Unpack``?)
-------------------------------------------

If these grammar changes are considered too burdensome, there are two
alternatives.

The first would be to **support change 1 but not change 2**. Variadic generics
are more important to us than the ability to annotate ``*args``.

The second alternative would be to **use ``Unpack`` instead**, requiring no
grammar changes. However, we regard this as a suboptimal solution for two
reasons:

* **Readability**. ``class Array(Generic[DType, Unpack[Shape]])`` is a bit
of a handful; the flow of reading is interrupted by length of ``Unpack`` and
mrahtz marked this conversation as resolved.
Show resolved Hide resolved
the extra set of square brackets. ``class Array(Generic[DType, *Shape])``
is much easier to skim, while still marking ``Shape`` as special.
* **Intuitiveness**. We think a user is more likely to intuitively understand
the meaning of ``*Ts`` - especially when they see that ``Ts`` is a
TypeVar**Tuple** - than the meaning of ``Unpack[Ts]``. (This assumes
the user is familiar with star-unpacking in other contexts, but if the
mrahtz marked this conversation as resolved.
Show resolved Hide resolved
user is reading or writing code that uses variadic generics, this seems
reasonable.)

If even change 1 is thought too significant a change, therefore, it might be
better for us to reconsider our options before going ahead with this second
alternative.

Backwards Compatibility
=======================