PEP 635: More arguments against '?' wildcards (#1665)

pep-0635.rst

@@ -782,9 +782,26 @@ items, capturing the first and last values.  While that may be the
 ultimate "wildcard", it does not convey the desired semantics.
 
 An alternative that does not suggest an arbitrary number of items
-would be ``?``.  However, this would require changes in the tokenizer,
-and it would put Python in a rather unique position:
+would be ``?``.  This is even being proposed independently from
+pattern matching in PEP 640.  We feel however that using ``?`` as a
+special "assignment" target is likely more confusing to Python users
+than using ``_``.  It violates Python's (admittedly vague) principle
+of using punctuation characters only in ways similar to how they are
+used in common English usage or in high school math, unless the usage
+is *very* well established in other programming languages (like, e.g.,
+using a dot for member access).
 
+The question mark fails on both counts: its use in other programming
+languages is a grab-bag of usages only vaguely suggested by the idea
+of a "question".  For example, it means "any character" in shell
+globbing, "maybe" in regular expressions, "conditional expression" in
+C and many C-derived languages, "predicate function" in Scheme,
+"modify error handling" in Rust, "optional argument" and "optional
+chaining" in TypeScript (the latter meaning has also been proposed for
+Python by PEP 505).  An as yet unnamed PEP proposes it to mark
+optional types, e.g. ``int?``.
+
+In addition, this would put Python in a rather unique position:
 The underscore is as a wildcard pattern in *every*
 programming language with pattern matching that we could find
 (including *C#*, *Elixir*, *Erlang*, *F#*, *Grace*, *Haskell*,