PEP 635: Add a rebuttal of PEP 642 (GH-1691)

Co-authored-by: Guido van Rossum <guido@python.org>

pep-0635.rst

@@ -893,6 +893,34 @@ patterns impossible.
           case (HttpStatus.NOT_FOUND):
               raise ResourceNotFound()
 
+:pep:`642` proposes using ``?`` as a prefix for *constraint patterns*: arbitrary
+expressions that replace the value and literal patterns defined here.  The PEP
+is motivated by a desire to "treat match patterns as a variation on assignment
+targets".
+
+We believe that attempting to unify the grammars of assignment targets and
+patterns is attractive, but misguided.  Evidence of this is PEP 642's need to
+introduce new syntax (which *neither* assignments nor our proposal requires) as
+a best attempt to unify them.  In contrast, consider function parameters and
+iterable unpacking: while they are certainly similar, they each have key
+syntactic incompatibilities that reflect their different purposes.
+
+It is also not clear from our research that there is need for value patterns to
+contain arbitrary expressions.  Any such dynamic elements can be easily
+expressed using one or more capture patterns together with a guard.  Having a
+clear separation between static and dynamic elements of patterns is a benefit,
+not a drawback [1]_.
+
+There are deeper issues as well.  Even if the grammars for both assignments and
+patterns are made "consistent" with one another, strings, byte-strings,
+mappings, sequences, and iterators will all behave differently in both contexts.
+This leaves us in a worse situation: one where the *grammar* is consistent, but
+the *behavior* differs in meaningful ways.
+
+The proposed syntax (prefixing arbitrary expressions with ``?``) is also quite
+ugly and distracting, harming readability.  (Our issues with using ``?`` as a
+wildcard symbol here have already been enumerated above.)
+
 
 Group Patterns
 ~~~~~~~~~~~~~~