[NOTE] I posted this on the python-ideas mailing list a day before the acceptance of PEPs 63[4-6]. No reply was made, so I am re/cross-posting it here. Given the steering council’s announcement, this is now more of a request for comment than an alternative syntax proposal.
Pattern matching re-surfaced on my radar today, along with the impression of a conclusion being just around the corner. Although this has seemed an ongoing state at times, a certain finality would come from a steering council decision. At the same time, it seems the polarisation that has developed around this feature has solidified more than dissipated. So I am prompted to throw my hat into the ring of language design.
However, I must acknowledge that it is very late in the development cycle of this feature. Given the sheer volume of previous discussion, I am uncertain if there is an appetite for further deliberation at this point. This post is an invitation to help clarify such uncertainty.
What I can bring to the table is a syntax design that is structurally close to PEP 634, but diverges significantly in detail and priorities. As to the content of this design, it seems best for the moment to give only a brief outline of significant differences. Laying out specific syntactic proposals seems a sure way to ignite a discussion which some/many may not wish to have.
- on a general level, it is a superset of both pattern matching and type hints.
- maybe this interferes with static typing efforts? Maybe it's a more flexible common ground?
- prioritises consistency with current syntax and 'style' of Python.
- to do so, introduces a new dunder method (single argument, boolean return).
- design began from interrogating arbitrary Python objects, rather than tuple unpacking.
- more 'object' oriented, but requires explicit/verbose notation of 'store' variables.
- centres around a new 'template' class, which any object can be 'queried' against.
- these can be created, customised and re-used outside of 'match' statements.
- [EDIT] No special casing of syntax within a branch expression ('|', '_', etc.)
- A more generalised solution is used to keep 'or' patterns brief
Since I didn’t set myself much of a conceptual ceiling, several optional extensions came about.
- a guard template to control whether the ‘match’ block is entered (e.g. integers only, then different ranges).
- opt-in fall-through on a per-branch basis.
- a new operator to utilise the new dunder method outside of ‘match’ contexts.
- an additional dunder method to improve brevity of repeated templates.
- a separate but related ‘assign’ block statement (shortcut for assignment to a common variable).
- outside of a ‘match’ context, using multiple template dispatch for functions/methods.
- [EDIT] and a few other tidbits for increased flexibility/control
Whatever the outcomes of this post and PEP 643, I will continue with my development of prototype emulations for current Python syntax. Discussion in this thread will help me decide on the degree of pace and detail to put into coding and communication efforts, e.g. PyPI and blog vs. full-on PEP.
Below is a description of my own context in relation to pattern matching. It is included primarily to elaborate on the motivation and timing of this post.
Shortly after the original publication of PEP 622, I began a loosely-bound train of thought on syntactic sugar in Python. My particular focus was on the clarity and consistency of future possibilities. Cue many iterations and multiple restarts from scratch.
I ended up with syntax designs ranging from generalised container merging to graph data structures. In order to more thoroughly iron out shortcomings, I have been on-and-off developing emulations using current Python syntax.
Meanwhile, pattern matching has continued on its own steam in the tuple-unpacking direction. After reading a variety of discussions, my takeaway impression was that in most cases the design was not particularly open to substantive changes. This seemed true at both a minute and broad scale. So I stepped away from these discussions to take the time to flesh out my own thoughts.
For myself, the most exciting idea within PEP 622 is switch-based control flow driven by custom predicates. In the current proposal, such predicates are optimised for a combination of structural unpacking and typing. A kind of inline abbreviated-expression dispatch. The escape hatch that I found to diversify predicate-space was to delegate all ‘matching’ details to a new class of objects. This enables the control of predicate logic outside of a ‘match’ statement, sidestepping the need to compress such details into an inline format.
On a final note…
As others do, I have my own likes and dislikes about the current form of pattern matching. Regardless of these opinions, I want to make clear that it is not my intention with this post to make a divisive affront to previous and ongoing efforts. If others wish to construe it as such, or take it to such a place, please instead spend your efforts building a reflective and much-less-binary dialogue around language design, rather than language designers.