You are right that just dismissing intuition is wrong. I should have
been more careful with my wording or explain them better, and I would
like to apologise if my response came across as too strong in this
The actual problem that I see is that we have different
cultures/intuitions fundamentally clashing here. In particular, so
many programmers welcome pattern matching as an "extended switch
statement" and find it therefore strange that names are binding and
not expressions for comparison. Others argue that it is at odds with
current assignment statements, say, and question why dotted names are
_/not/_ binding. What all groups seem to have in common, though, is
that they refer to _/their/_ understanding and interpretation of the
new match statement as 'consistent' or 'intuitive'---naturally
pointing out where we as PEP authors went wrong with our design.
But here is the catch: at least in the Python world, pattern matching
as proposed by this PEP is an unprecedented and new way of approaching
a common problem. It is not simply an extension of something already
there. Even worse: while designing the PEP we found that no matter
from which angle you approach it, you will run into issues of seeming
'inconsistencies' (which is to say that pattern matching cannot be
reduced to a 'linear' extension of existing features in a meaningful
way): there is always something that goes fundamentally beyond what is
already there in Python. That's why I argue that arguments based on
what is 'intuitive' or 'consistent' just do not make sense _/in this
case/_. I think the discussion on this mailing list with the often
contradictory views, proposals, and counter-proposals more than makes
As for your argument that it looks like calling a function or creating
an object: I tried to explain a little while ago that you'd be well
advised to rather approach it as something similar to a function
_/definition/_. After all, the part after `def` in `def foo(a, b):`
also looks like a function call! But nobody seems to mind this
similarity in syntax there! And the target in `(a, b) = c` looks like
a tuple constructor, although it actually is the exact opposite.
Finally, I completely agree that intuition is informed by experience
and serving us very well. The first part of this, however, is also to
say that intuition is malleable thing! And experience from other
programming languages who took the leap to having pattern matching
shows that it quickly becomes a quite intuitive and easy to use feature.
P.S. Please excuse my late reply; I am currently on vacation.
Quoting Larry Hastings
On 7/31/20 12:36 AM, Tobias Kohn wrote:
And since pattern matching is really a new feature to be introduced to Python, a feature that can be seen in different lights, there is no 'Python-Programmer intuition' that would apply in this case.
It's not fair to say "intuition doesn't apply because it's new syntax". There are plenty of examples of intuition serving a Python programmer well when encountering new syntax. A Python programmer's intuition is informed by existing syntax and conventions in the language. When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.
Take for example list comprehensions. Python 1 programmers hadn't seen
a = [x for x in y]
But they knew what square brackets meant in that context, it meant "creates a new list". And they knew what "for x in y" meant, that meant iteration. Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately.
The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics. For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different. Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key. Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.