Hi Larry,

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 regard.

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 my point.

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 <larry@hastings.org>:


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.