On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum, <guido@python.org> wrote:
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
The key thing I'm hoping for in PEP 622 itself is that "Syntactic
compatibility with a possible future enhancement to assignment
statements" be considered as a constraint on the syntax for case

That would certainly rule out ideas like writing stores as $x or x? or <x> etc., since it would be syntactically incompatible with *current* assignment statements.

Yeah, having stores be unmarked is perfectly consistent with existing assignment statements and expressions, so I now think the PEP is correct to propose that.

However, the two parts of the match lvalue proposal that are a genuine problem from a syntactic consistency perspective are:

* using "." to mark value constraints (already means attribute binding in assignment lvalues)
* using "_" to mark wildcard placeholders (already means a normal variable binding in assignment lvalues)

The conclusion I came to from that observation was that to allow for potential future syntactic consistency, it isn't variable bindings that need a symbolic prefix in match lvalues, it's value constraints.

That then leads to the idea of using "?" as a general "value constraint" marker in match expressions:

* bare "?": wildcard placeholder that allows any value without binding it
* prefix "?": constrains the value in that position without binding it
* infix "?": imposes a value constraint on a value that is being bound to a name (means the walrus matching pattern is only needed in cases where a value is being both bound and deconstructed - simple cases would be written like "name?None" rather than "name:=None")

With this spelling, the named value constraint example from the PEP would look like this (with an extra case added showing infix value constraints):

match color:
    case (primary?GREEN, highlights?BLUE):
        print("Two tone, huh? Nice!")
    case ?BLACK | ?Color.BLACK:
        print("Black suits every color")
    case BLACK: # This will just assign a new value to BLACK.

I'll note that adopting this approach would likely mean that "?0", "?None", etc would qualify as legal value constraints, so a separate decision would need to be made if it was allowed to omit the prefix for literal constraints on values that weren't being bound to a name.

A decision would also need to be made on whether the RHS of "?" constraints was permitted to be a full expression or not (e.g. if function calls were allowed, I believe there would be significant potential for confusion with class constraints).