On Wed, Aug 5, 2020 at 8:14 PM Larry Hastings <larry@hastings.org> wrote:
It's interesting to consider how C# did it. For example, at the same time they added pattern matching, they also added "discards", which are (undeclared-only?) variables whose name starts with '_' and whose value is never retained. I'm not sure, but I believe the language previously permitted (and still permits) conventional variables that started with '_'. My guess is that that's now discouraged, and new code is encouraged to only use identifiers starting with '_' as discards.
And, a minor correction: C# added pattern matching (and discards) in version 7, though they did extend the syntax in version 8.
Yes, that was my goal when I asked about pattern matching added to a language after its initial design: maybe we could learn something about how to adopt this feature gradually instead of all at once.
Cheers,
/arry
On 8/5/20 2:04 PM, Robert White wrote:
Off the top of my head for recently happened and fairly mainstream language: C# added it in 8.0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-p...
On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho <luciano@ramalho.org> wrote:
On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@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 <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.
Cheers,
/arry
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/2VRPDW4E... 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-leave@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/PI44AV5C... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/PZMWDYEL... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/CGR7J6B2... 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