[Python-Dev] Re: PEP 622: Structural Pattern Matching
Hello everyone, this is my first crack at commenting on a PEP, so apologies for
mistaking any developer colloquialisms, or if this is the wrong channel to go
through.
In a nutshell, I was mulling over my initial difficulty in understanding name
patterns and had the thought of ‘declaring’ so-called ‘placeholder’ variables
at the beginning of the match block, so that the reader is ‘primed’ for their
use throughout:
x_literal = a_value
y_literal = another_value
match point:
proxy x, y
case (x_literal, y):
print(f”Y={y} at literal X”)
case (x, y_literal):
print(f”X={x} at literal Y”)
case (x_literal, y_literal):
print(“That is the literal point”)
case (x, y):
print(f”Arbitrary point: X={x}, Y={y}”)
case _:
raise ValueError(“Not a point”)
The use of ‘proxy’ instead of ‘placeholder’ is simply an attempt at brevity
without diverging substantially from the meaning.
The use of a placeholder variable reminded me a lot of comprehensions, which
are explicit in where placeholders come from, but only towards the end of the
comprehension:
y = [f(a, b) for a, b in iterable]
A contrasting example is the lambda function, which ‘declares’ its placeholders
upfront:
y = map(lambda x, y: f(x, y), iterable)
In reading these two examples left to right, I believe that it is easier to
understand the lambda function in a first pass, whereas the list comprehension
often requires looking back at the expression after reading the ‘for’ clause at
the end. This difference in first-pass understanding becomes more apparent when
the expression or function is more complex. In this vein, ‘declaring’
placeholder variables upfront makes sense to me when the context in which they
can be used is (relatively) large and not self-contained.
Now, this does add “new syntax”, which is addressed in the ‘Alternatives for
constant value pattern’ section of the PEP; but in reading this thread, it
seems like such a solution remains appealing. For myself, a one-off
‘declaration’ with a reasonably unambiguous keyword like proxy makes the code
easier to follow as one reads through it, without the need for variables to be
typed out differently (consistent with all other variable usage).
I reckon something like this idea would improve comprehensibility (not just raw
readability) and is more in line with other prose-like constructs in Python
(try/except, with, and/or). This is particularly important for people that are
new to either this feature (everyone at first), or the language as a whole.
Not being all too familiar with CPython implementation details myself, my idea
is certainly open to technical critique (and of course qualitative
impressions). As a bit of a stab in the dark, ‘proxy’ could be a soft keyword
within a match block, similar to ‘match’ being a soft global keyword.
___
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/FRC5ZNXQPWWA4D2SJM4TYWMN5VALD3O6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
> match get_node() into c: +1 to scoping name pattern related objects upfront. (mirrors my post, so no bias :P) Using a namespace to group capture variables is a good idea, though new attributes are introduced throughout the match block. In my view, this is very similar to the use a special character like '$', the difference being that such a modifier can be 'named'. I second your idea of an 'into' keyword to align the match statement with others in Python. It was a consideration of mine, but I was likewise wary of the first-line verbosity. I think it's worth it for the increased familiarity, especially since capture variables are in a sense auxiliary to the match statement (so just pop them at the end). Flattening your capture object into individual variables does this while still being explicit from the beginning about what variables can be used for name matching: match get_node() into a, b, c: As far as the naming of the 'into' keyword, I think yours is a solid candidate. Others are sure to present a healthy range of alternatives I'm sure :). My only preference would be that the qualification of the match statement is appended, rather than done in place like match(a, b, c) get_node(): ___ 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/C6EP2L66LBJKT5RHDE6OIKG7KWM2NMLV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
I don't mean to be rude, but I would like to chip in and back up Taine here. The 'or' operator: - Already unambiguously associated with a logical OR, which is effectively what takes place in this circumstance. Using a different symbol to have the same effect is bound to be confusing to a reasonably large number of people. The '|' character: - Saves one character, but I think it would be easier to miss compared to a keyword which is easy to highlight in an editor. - It's existing usages are very context-specific (between two dict objects, within a regex expression) - using it here I think would start to bring it into the language in a more general way. Because of this, I think a more holistic discussion on its place within Python is appropriate before it is reached for as a bespoke solution. ___ 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/FPYVL42BPC3LMK62WWY7J37AKGMXXDSD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
After reading a GitHub discussion on the matter (https://github.com/gvanrossum/patma/issues/93), '|' now makes sense to me instead of 'or': - The use of the '|' character in Python seems to be going towards a union-like operator (dict merging, PEP 604), which is definitely appropriate here. - The clarity of '|' and 'or' can go either way subjectivity, but a use-case I hadn't considered in my previous comment was nested pattern matching, e.g. case (1 | 2 | 3, x) | (4 | 5 | 6, x): case (1 or 2 or 3, x) or (4 or 5 or 6, x): To me, '|' seems at least as clear as 'or' in this case, since it can be read faster and doesn't chew up space. Spaces before and after '|' definitely help. - As Tim noted, 'or' would exist as a solitary logical function in the current setup. Although, a different GitHub discussion could possibly ressurect 'and' (https://github.com/gvanrossum/patma/issues/97). ___ 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/4OQET2DXBQUV3ZJNKFUS7O4JB5V7GZ5U/ Code of Conduct: http://python.org/psf/codeofconduct/
