On Thu, 2 Jul 2020 at 00:50, Guido van Rossum
Before we all get a little too excited here, I think that allowing ``` 1 = x ``` as a sneaky way of writing ``` assert x == 1 ``` would be a terrible mistake.
The "two ways to do it" possibilities give me pause too, but it wouldn't be exactly the same as assertions or type annotations, since it would still be executed even when optimisations were enabled, and would impose a runtime check, not just a static type analysis check. The structurally split nature of the construct would also allow the default error message to be along the lines of `"AssertionError: Value {:100!r} does not match constraint {!100:!r}".format(rhs_value, lhs_literal_text)`, and still allow type analysers to make relevant inferences. (Although whether the exception should be AssertionError, ValueError, or a new exception type entirely would be open to discussion)
As to allowing object destructuring syntax like ``` Point(x, y) = p ``` that definitely has merit, but it is a complex subject that should be a separate PEP.
This is the main point I'm actually interested in, and I agree it should be a separate PEP. 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. Some of the ideas currently on the table would rule that out, since they re-use syntax that is already legal in assignment statements to mean something else (most notably, "x.y = z" means something entirely different from the initially proposed meaning of "case x.y:"). If PEP 622 were to be accepted in that form, then it would foreclose the possibility of ever allowing destructuring assignment statements. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia