I think using symbols like ? and == in patterns looks stylistically ugly, and unintuitive, albeit more explicit. I, too, would rather have pattern matching more explicit, but it shouldn't need to be so ugly (yes, I know, ugly is a subjective term, so be it). I would propose that, opposite to what this PEP 642 proposes, matching as literal terms should be the default, and a special notation should be used for binding to names. match number: case 0: print("Nothing") case 1: print("Just one") This would be equivalent: zero = 0 one = 1 match number: case zero: print("Nothing") case one: print("Just one") And I would propose to use "as" for the notation of binding to a variable, possibly in combination with "_" for the wildcard pattern: expected_value = "xxx" match some_json: case {"foo": expected_value}: # matches {"foo": "xxx"} pass case {"foo": _ as bar}: # matches any {"foo": <anything>} print(f"json got foo value {bar}") Yes, I understand that being forced to use "_ as name" in a lot of patterns is more verbose, but I posit that it is both explicit _and_ intuitive. And perhaps not as ugly as ? and ==. In my mind, I don't see that this "as" usage causes any confusion with the "as" in context managers. That is a cop-out. I see this "as" as more akin to the exception handling: try: ... except RuntimeError as error: ... See? No context manager protocol involved here. "as" is simply representing a name binding. On Sat, 31 Oct 2020 at 07:17, Nick Coghlan <ncoghlan@gmail.com> wrote:
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/WT3ZZ42X... Code of Conduct: http://python.org/psf/codeofconduct/
-- Gustavo J. A. M. Carneiro Gambit Research "The universe is always one step beyond logic." -- Frank Herbert