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

pep-0646.rst

@@ -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
-------------
+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
-   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.
+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 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
 =======================