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 <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia
> _______________________________________________
> 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/WT3ZZ42XJ4G6Y3H26RWUFN5GCUIFLMQ7/
> 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
_______________________________________________
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/3Q5KSGEXWGNC5JNUIXNTZJB4Q36IM3DY/
Code of Conduct: http://python.org/psf/codeofconduct/
