On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum, <gu...@python.org> wrote:
> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan <ncogh...@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
>> 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.
>
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/M5KD3YVIJXLBIXFYN73YUWFCR57KLHAW/
Code of Conduct: http://python.org/psf/codeofconduct/
