On 11/2/2020 9:31 AM, Thomas Wouters wrote:
On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano <st...@pearwood.info
<mailto:st...@pearwood.info>> wrote:
I really don't get why so many people are hung up over this minuscule
issue of giving `_` special meaning inside match statements. IMO,
consistency with other languages' pattern matching is more useful
than
the ability to capture using `_` as a variable name.
Allow me to explain, then: structured pattern matching is (even by
admission of PEPs 634-363) an extension of iterable unpacking. The use
of '_' as a wildcard pattern is a sharp break in that extension. In
the structured pattern matching proposal, '_' is special syntax (and
not in any way less so than '?') but *only* in cases in match
statements, not in iterable unpacking. It *already* isn't consistent
with '_' in other languages, and we can't fix that without breaking
uses of _ for gettext, not to mention other situations existing code
uses '_' as something other than an assign-only variable.
Using '_' in structured pattern matching means any use of '_' becomes
an extra burden -- you have to know whether it's a name or not based
on the surrounding context. It makes all uses of '_' harder to parse,
and it makes it easier to mistake one situation for another. Perhaps
not terribly easy, but since there is _no_ confusion now, it's by
definition *easier*. The use of something else, like '?', leaves
existing uses of '_' unambiguous, and allows structured pattern
matching and iterable unpacking to be thought of the same. It reduces
the complexity of the language because it no longer uses the same
syntax for disparate things.
All good points.
What I don't understand is why '_' is treated any differently than any
named capture pattern. It seems to me that using:
case x: # a capture_pattern
is the same as:
case _: # the wildcard_pattern
They both always match (I'm ignoring the binding thing here, it's coming
up). I realize PEP 635 gives the rational for separating this so that it
can enforce that "case x, x:" can be made invalid, likening it to
duplicate function parameters. The PEP focuses on the differences
between that and tuple unpacking. But I think that if the semantics were
the same as tuple unpacking (allowed duplicates, and binding to the last
one) then the whole "_ as wildcard" arguments would just go away, and
"_" would be treated just as it is elsewhere in Python. For me, this
would address Thomas' point above and reduce the cognitive load of
having a special rule.
But I'm probably missing some other nuance to the whole discussion,
which will no doubt now be pointed out to me.
Eric
_______________________________________________
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/URM22DOSDT7YKI4HFR2ACKY3K3HTHYZP/
Code of Conduct: http://python.org/psf/codeofconduct/
