On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <ko...@tobiaskohn.ch> wrote: > 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.
The languages I know about that have pattern matching had it from the start as a core feature. I am curious to learn about languages that adopted pattern matching later in their evolution. Cheers, Luciano > > 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/ -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ 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/PI44AV5C2F2IMO6PJSYVJOPXGQ62JMHQ/ Code of Conduct: http://python.org/psf/codeofconduct/
