Unfortunately there are millions of ideas. The PEP authors are taking the dilemma seriously and we are deliberating what to do.
On Thu, Jul 2, 2020 at 4:04 PM Nick Coghlan email@example.com wrote:
On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum, firstname.lastname@example.org wrote:
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan email@example.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 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
- 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).