I think that creating a "matching assignment" operator is unnecessary at this point. I think the original point of bringing this up as part of PEP 622 is to try to suggest that the syntax for binding a value not be incompatible with a future version of Python where that same syntax can be used for any kind of assignment. That goal is not satisfied for all cases if `case self.x` means anything except "bind the value to `self.x`".
I think that you /could /probably still use $, ? or <> to mark a variable to be bound, but it would /not/ be worth the effort to make it mandatory for lvalues in general, and if you make it optional I imagine it would be rarely used, and you'd get effectively no benefit from supporting that (since people would just be confused whenever they saw it).
I think that leaves as /realistic/ options here to either abandon the idea of marking read vs. store, put the marker on variables to be read (and have it be something other than "there is a . anywhere in the expression"), or abandon the goal of allowing for perfect symmetry between lvalues in case statements and lvalues in assignments.
I tend to think "mark all reads" is the best course of action here, and stuff like `case self.x` would be a `SyntaxError` (like it is with assignment expressions).
On 7/2/20 12:26 PM, MRAB wrote:
On 2020-07-02 15:48, Jim J. Jewett wrote:
Guido van Rossum 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.
No; it would be unfortunate that it creates a second way to do things, but it wouldn't rule them out. The problem Nick pointed out is for syntax that is already meaningful, but means something different.
self.y = 15
already has a meaning, but that meaning is NOT "don't really assign to X, I am using it as a constant defined elsewhere."
?x = 14 ?self.y = 15
do not yet mean anything, and if they end up being a more explicit (but also more verbose) variant of
x = 14 self.y = 15
that is probably sub-optimal, but it isn't any worse than :=
The slight variation triggered by the "?" of ?var would be shorthand for "and if you can't make the entire assignment work, pretend I never even asked", so that
?x, 0 = (4,5)
would not lose or shadow a previous binding of x.
IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not.
There could be another form that does matching:
try ?x, 0 = (4,5)
?x, 0 ?= (4,5)
Perhaps it could also be used as an expression, having the value True if it matches and False if it doesn't. _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/MQV7WBAS... Code of Conduct: http://python.org/psf/codeofconduct/