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
in 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.
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.
- an additional dunder method to improve brevity of repeated templates.
- a new operator to utilise the new dunder method outside of 'match'
contexts.
- 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.
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 class inheritance. 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.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/AINHP6H2REQFPKRKNSUSVABTNUZWHEBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
