Hello,
On Tue, 12 Jan 2021 00:11:33 +1000
Nick Coghlan
On Sun, 10 Jan 2021, 7:37 pm Paul Sokolovsky,
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:pmiscml@gmail.com