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. 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 <mailto:luciano@ramalho.org>> wrote:
On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <kohnt@tobiaskohn.ch <mailto: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 <mailto: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 <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-leave@python.org <mailto: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 <mailto:python-dev@python.org> To unsubscribe send an email to python-dev-leave@python.org <mailto: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/