Hi folks, This is a mailing list repost of the Discourse thread at https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structura... The rendered version of the PEP can be found here: https://www.python.org/dev/peps/pep-0642/ The full text is also quoted in the Discourse thread. The remainder of this email is the same introduction that I posted on Discourse. I’m largely a fan of the Structural Pattern Matching proposal in PEP 634, but there’s one specific piece of the syntax proposal that I strongly dislike: the idea of basing the distinction between capture patterns and value patterns purely on whether they use a simple name or a dotted name. Thus PEP 642, which retains most of PEP 634 unchanged, but adjusts value checks to use an explicit prefix syntax (either `?EXPR` for equality constraints, or `?is EXPR` for identity constraints), rather than relying on users learning that literals and attribute lookups in a capture pattern mean a value lookup check, while simple names mean a capture pattern (unlike both normal expressions, where all three mean a value lookup, and assignment targets, where both simple and dotted names bind a new reference). The PEP itself has a lot of words explaining why I’ve made the design decisions I have, as well as the immediate and potential future benefits offered by using an explicit prefix syntax for value constraints, but the super short form goes like this: * if you don’t like match statements at all, or wish we were working on designing a C-style switch statement instead, then PEP 642 isn’t going to appeal to you any more than PEP 634 does * if, like me, you don’t like the idea of breaking the existing property of Python that caching the result of a value lookup subexpression in a local variable and then using that variable in place of the original subexpression should “just work”, then PEP 642’s explicit constraint prefix syntax may be more to your liking * however, if the idea of the `?` symbol becoming part of Python’s syntax doesn’t appeal to you, then you may consider any improved clarity of intent that PEP 642 might offer to not be worth that cost Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia