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.md
_______________________________________________
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/7OA6N45NZZ64HPLS6PFJ4DCN2LHULCEZ/
Code of Conduct: http://python.org/psf/codeofconduct/
