Steven D'Aprano writes:
Oh, I'm sorry, I based my comment on Chris' comment that Mark was repeating everyone else's arguments. My bad :-(
Mark can be tendentious. Some of his arguments in the main gist were also made by others, but mostly they do seem to be reiterations of his own pet peeves. That said, I think Guido was unfair. Mark's pamphlet does provide a lot of new data for us to consider, not so much in the main "Critique", but rather in the "Analysis of the Standard Library"[1]. To me, the "queries" he came up with seem a fair representation of the kinds of things that this proposal might improve in the stdlib. I found that Mark's rewritings are generally pretty attractive even though they seem unlikely to provide substantial decrease in LOC and quite unlikely to be more performant. I like destructuring as a way of "breaking out" attributes to local bindings. I think most of the pattern matching versions are distinct improvements over both the existing code and Mark's suggested alternatives, although pattern matching is a "big change" and his alternatives have much smaller footprints on the future of Python. I would make a few points based on little expertise in pattern matching ;-), my esthetic sense about destructuring, and Mark's critique and analysis. 1. In the Critique Mark argues use of pattern matching is likely to be infrequent because of the heavy use of duck typing in well- written Python code. But I find pattern matching to be complementary to duck-typing. To be a bit melodramatic, it's an extension of duck-typing from "walks and quacks like a duck" ("dynamic duck-typing") to "has a bill like a duck" ("static duck-typing" or perhaps "platypus mistyping"). 2. In the Analysis Mark argues that idioms amenable to pattern matching in existing stdlib code are quite rare (a couple of dozen instances, and as I wrote above I think his query was reasonably representative). While that certainly is a useful analysis, it cannot account for the fact that pattern matching is a *paradigm* that has not been available in Python in the past. *Availability of a pleasant syntax for a new paradigm causes code to be designed differently.* That is something that none of us can claim to be able to quantify accurately, although the experience Guido and others have with "async" may be relevant to guesstimating it. 3. Mark identifies a number of minor deficiencies in the existing proposal, of which the attractive nuisance of "symbolic constants" (the "case HTTP_OK" example) and the inability to use pattern matching directly to populate object attributes in __init__ methods were most impressive to me. (I still like the PEP.) I wonder if it would be possible to provide hooks for a useful amount of pattern matching syntax while leaving open the possibility of future semantic improvements as was done with function annotations.
I guess at some point I shall have to read the entire thread if I want to have an opinion on this feature.
Only if the SC refuses to approve the current draft! ;-) [1] https://github.com/markshannon/pep622-critique/blob/master/stdlib_examples.m...