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-pattern-matching-in-csharp-8-0
On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho <luci...@ramalho.org
<mailto:luci...@ramalho.org>> wrote:
On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn <ko...@tobiaskohn.ch
<mailto: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
<mailto: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
<mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
<mailto: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
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto: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/
_______________________________________________
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/PZMWDYELYFYRDV3TZ3B4KLEPCJPN4JFB/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/CGR7J6B2XH3C5FF5HBJ76VAOEAWIXACH/
Code of Conduct: http://python.org/psf/codeofconduct/
