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 <ncogh...@gmail.com> wrote:
> 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.
>
>>
>
>>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
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/BWG5N23WBPFDEORGPK43R7N4A6KBRLV6/
Code of Conduct: http://python.org/psf/codeofconduct/
