Acceptance of Pattern Matching PEPs 634, 635, 636, Rejection of PEPs 640 and 642
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language.
We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient.
At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal.
Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10.
We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it.
Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature!
-The Python Steering Council
On 2/8/2021 3:07 PM, Python Steering Council wrote:
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs.
Thank you for your collective time and efforts. I agree with preferring 634 to the alternatives. I don't know what I would have decided after the additional discussion you all have had. I do think that for a big addition like this, a collective decision is better than one person deciding (including for the one person).
We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient.
I agree and appreciate this. There have been new features release without adequate documentation. This requirement means that you had to decide now or very soon or likely put this off to 3.11.
The one thing I think needs to be discussed and not been much, at least not publicly that I have seen, is whether we really want to go down the road of contextual keywords. There are some negatives as well as positives. Just because the new parser makes them possible does not mean we should. Do we really want to see 'match match:' or 'case match...', etc? Where possible, should we retroactively make existing keywords contextual?
This is really independent from the resst of this PEP since we could do the traditional thing of deprecate non-keyword uses of 'match' and 'case' and require a __future__ import for immediate use thereof.
Terry J. Reedy
On Tue, 9 Feb 2021, 6:21 am Python Steering Council, < steering-council@python.org> wrote:
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language.
Thank you for resolving this discussion - I'm sure it wasn't an easy decision.
Obviously I think we're going to find things to regret in the way name binding works in class and mapping patterns, but I also think using "_ as name" as an explanatory tool is likely to cover most of them.
I'll also consider submitting a PEP *adding* explicit patterns to the implicit ones, rather than proposing to replace them, so the handling of different kinds of bare expressions can be readily explained as syntactic shorthand for more explicit operations rather than the shorthand being the only available spelling.
I won't do that until after helping with the review of the main PEP 634 implementation, though.
Cheers, Nick.
On Tue, 9 Feb 2021, 8:18 am Terry Reedy, <tjreedy@udel.edu> wrote:
The one thing I think needs to be discussed and not been much, at least not publicly that I have seen, is whether we really want to go down the road of contextual keywords. There are some negatives as well as positives. Just because the new parser makes them possible does not mean we should. Do we really want to see 'match match:' or 'case match...', etc?
As a hard keyword, the existence of "re.match()" would have almost certainly resulted in immediate rejection of the PEP.
Where possible, should we retroactively make existing
keywords contextual?
The benefit of contextual keywords is being able to choose popular method/function/variable names as new keywords without a disruptive deprecation and migration process. That benefit doesn't apply to existing keywords.
Cheers, Nick.
On 2/8/21 3:02 PM, Nick Coghlan wrote:
On Tue, 9 Feb 2021, 8:18 am Terry Reedy wrote:
The one thing I think needs to be discussed and not been much, at least not publicly that I have seen, is whether we really want to go down the road of contextual keywords. There are some negatives as well as positives. Just because the new parser makes them possible does not mean we should. Do we really want to see 'match match:' or 'case match...', etc?
As a hard keyword, the existence of "re.match()" would have almost certainly resulted in immediate rejection of the PEP.
Where possible, should we retroactively make existing keywords contextual?
The benefit of contextual keywords is being able to choose popular method/function/variable names as new keywords without a disruptive deprecation and migration process. That benefit doesn't apply to existing keywords.
No, but it would have the benefit of allowing existing keywords to be reused where it makes sense; a recent example I
came across is the Tcl/Tk interface -- Tk has a method named raise, but it has to be renamed to tkraise because of the
keyword clash (it's also given a lift alias).
-- ~Ethan~
On Tue, Feb 9, 2021 at 7:11 AM Ethan Furman <ethan@stoneleaf.us> wrote:
Where possible, should we retroactively make existing keywords contextual?
The benefit of contextual keywords is being able to choose popular method/function/variable names as new keywords without a disruptive deprecation and migration process. That benefit doesn't apply to existing keywords.
No, but it would have the benefit of allowing existing keywords to be reused where it makes sense; a recent example I came across is the Tcl/Tk interface -- Tk has a method named
raise, but it has to be renamed to tkraise because of the keyword clash (it's also given aliftalias).
This is a reasonable idea, with definite pros and cons. I recommend starting a separate thread about that.
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
participants (5)
-
Ethan Furman -
Guido van Rossum -
Nick Coghlan -
Python Steering Council -
Terry Reedy