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.
Cheers,
Tobias
P.S. Please excuse my late reply; I am currently on vacation.
Quoting Larry Hastings <la...@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.
Cheers,
//arry/
_______________________________________________
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/2VRPDW4EE243QT3QNNCO7XFZYZGIY6N3/
Code of Conduct: http://python.org/psf/codeofconduct/
