iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 646: Add additional motivation for why *Ts over Unpack[Ts] (#2054)

This commit is contained in:
Matthew Rahtz 2021-08-23 22:26:52 +02:00 committed by GitHub
parent b89333c73b
commit cebfa33baa
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
pep-0646.rst
View File

@ -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 and simple tests to confirm correct behaviour are available at
https://github.com/mrahtz/cpython/commits/pep646-grammar. 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, The first grammar change enables use of star expressions in index operations (that is,
within square brackets), necessary to support star-unpacking of TypeVarTuples: 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] 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. 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 Again, prevention of such annotations will need to be done by, say, static
checkers, rather than at the level of syntax. checkers, rather than at the level of syntax.
Alternatives Alternatives (Why Not Just Use ``Unpack``?)
------------ -------------------------------------------
If these two grammar changes are considered too burdensome, there are two alternatives: If these grammar changes are considered too burdensome, there are two
alternatives.
1. **Support change 1 but not change 2**. Starred expressions within indexes are The first would be to **support change 1 but not change 2**. Variadic generics
more important to us than the ability to annotation ``*args``. are more important to us than the ability to annotate ``*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 The second alternative would be to **use ``Unpack`` instead**, requiring no
more readable. 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 mouthful; the flow of reading is interrupted by length of ``Unpack`` and
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; if the
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 Backwards Compatibility
======================= =======================