On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum,
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan
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 patterns.
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). Cheers, Nick.