Hello,
On Tue, 12 Jan 2021 00:11:33 +1000
Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky, <pmis...@gmail.com>
> wrote:
>
> > And I patiently continue this thread, hoping that people whose
> > argument would be along the lines of "I teach Python, and I don't
> > want to teach my students 2 ways of doing the same thing, and which
> > way use when. Why, if PEP634 offers just one way?"
> >
>
> They don't do the same thing, though. One does traditional duck typing
> (checking for the presence of a specified set of attributes on an
> object), while the other matches a sequence of attributes specified
> by the class.
Yes, as I mentioned, I grokked the "construction" you made in your PEP,
and under given premises, it's a neat construction. But I don't think
that premises under which you did that are "right".
And from point of view of an average Python programmer, they both apply
to objects, so from that PoV, they "do the same thing".
> PEP 634 just conflates the two tasks into a single call-like syntax
> that may or may not bare any resemblance to the type's constructor
> signature.
But pattern matching concept in the first place conflates "instance-of"
checks and usual one-by-one comparisons of contained values with some
references, and extraction of other contained values.
That's how we treated the matter for decades - we knew that on the
other side, the esoteric functional languages use "pattern matching".
And we smiled at that, and told ourselves that our imperative languages
are more expressive - by combining our individual "isinstance" and
scalar comparisons we can easily achieve the same effect as pattern
matching, but also tons of other effects. Fast forward, and we have
slightly adjusted definition of "expressivity" - it's not "when you can
do anything with low-level means, combining them verbosely", it's "when
you can do practically useful things concisely/without extra verbosity".
In that regard, PEP642:
1. Steals some generality/expressivity from PEP634, limiting "Cls(a, b)"
style patterns to only classes which define __match_args__.
2. Hastily adds new pattern matching syntax, "obj{.a, .b}". But PEP634
forecasts that beyond patterns which it describes, it's easy to imagine
that over time, more of useful patterns can be added (up to
user-defined patterns). It just says that it doesn't want to haste with
trying to defining those right away, instead tries to lay the
grounds for the pattern matching per se.
> Cheers,
> Nick.
--
Best regards,
Paul mailto:pmis...@gmail.com
_______________________________________________
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/CW2MFXT5CCOVY7PLJ3XUOAGLGIFG2H3V/
Code of Conduct: http://python.org/psf/codeofconduct/
