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-structural-pattern-matching/5614

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/WT3ZZ42XJ4G6Y3H26RWUFN5GCUIFLMQ7/
Code of Conduct: http://python.org/psf/codeofconduct/