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 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. >> >> 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) > > or: > > ?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 -- 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/MQV7WBASYRI7PJT5M2VUCPHKBZLXDMY2/ > Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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/XCHCK7ZXS3OEKOLRGJGS7USFXGBFSIBT/ Code of Conduct: http://python.org/psf/codeofconduct/
