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 2020-07-02 15:48, Jim J. Jewett wrote:
Guido van Rossum wrote:IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not.
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan firstname.lastname@example.org 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
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.
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 -- email@example.com
To unsubscribe send an email to firstname.lastname@example.org
Message archived at https://email@example.com/message/MQV7WBASYRI7PJT5M2VUCPHKBZLXDMY2/
Code of Conduct: http://python.org/psf/codeofconduct/