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/21 12: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.
Yay! Congratulations Guido, Brandt, Tobias, Daniel, and Talin! -- ~Ethan~
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.
Hello, On Tue, 9 Feb 2021 08:56:02 +1000 Nick Coghlan <ncoghlan@gmail.com> 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.
Also, +100 for resubmitting on its own just the part of PEP642 which adds "== EXPR" and "is EXPR" syntax, to match by expression value (i.e. where PEP642 initially started from).
I won't do that until after helping with the review of the main PEP 634 implementation, though.
Cheers, Nick.
-- Best regards, Paul mailto:pmiscml@gmail.com
I came across 640 this morning -- if it's rejected, shouldn't the status be updated from Draft to Rejected? https://www.python.org/dev/peps/pep-0640/
participants (5)
-
Ethan Furman -
gerardw＠alum.mit.edu -
Nick Coghlan -
Paul Sokolovsky -
Python Steering Council