Hi Terry, Thank you: I really like your wave/particules analogy. I think that pattern matching is indeed uniting different concepts to build a stronger, more versatile structure. I also like your concept of a general "binding structure" with different forms, such as assignment, parameter passing, and (according to PEP 622) patterns. I feel that this categorisation puts pattern matching quite in the correct place. Of course, there is also the second aspect of "bind these variables---/if you can/" or "analyse and compare the structure", which is the other part of this particule/wave duality. Concerning the guards (optional conditions), I also think that you summarised very nearly. I tend to think of the patterns a bit like the grammar of a programming language. Something that is supposed to be static and declarative (as far as this is possible in Python). Yet, some constraints in programming languages cannot be expressed by a (context-free) grammar in a meaningful way. For instance, the grammar itself does not keep you from having two parameters in a function sharing the same name. This is a dynamic aspect, a relationship between two otherwise independent parts of the overall structure. And that is best caught by the guards. So, yes: as I see it, the guards really add something that goes beyond the declarative side of patterns. Hence, I completely agree with your characterisation. Kind regards, Tobias Quoting Terry Reedy <tjreedy@udel.edu>:
On 7/16/2020 9:51 PM, Tobias Kohn wrote:
Hi Everyone,
I feel there are still quite a few misconceptions around concerning PEP 622 and the new pattern matching feature it proposes. Please allow me therefore to take another attempt at explaining the ideas behind PEP 622 with a different approach. Bear in mind that I naturally cannot cover everything, though, and that some parts presented here are still slightly simplified.
Thank you Tobias. I am a fan of looking at things from multiple viewpoint. For 200 years, physicists argued about whether light is waves or particles, before discovering that 'neither' and 'both' were more correct.
1. Function Overloading 2. Visitor Pattern and Dispatch > 3. Shape and Structure
[snip, snip, snip]
In an assignment statement, the code to the left of '=' is a 'target list' of 'target's, with some idiosyncratic rules. Even though it might, misleadingly, be called a 'target expression', it is not an expression to be evaluated. Similarly, the code between parentheses in a def statement is a 'parameter list' of 'defparameter' and special symbols, with other idiosyncratic rules. Both could be called 'binding lists' or more generally, 'binding structures'.
To me, the important point of your point is that 'case' is somewhat analogous to 'def', and that the stuff between 'case' and ':' is a binding structure. We should call this structure a 'match structure'. It is misleading and confusing to call it a 'match expression'. A match structure consists of a 'match list' of 'match items' or 'matcher's and an optional "'if' <condition>".
Matchers have a 3rd, new, and larger set of idiosyncratic rules. The optional condition is an escape hatch for when expressing the intended match constraint and corresponding match set is difficult or worse using the match rules.
As with target and parameter items, untagged simple name matchers are (and I now see, should be) binding targets. (The parameter list tags are ':' for types and '=' for default values.) Unlike assignment targets, dotted names and subscriptings are not binding targets. Like parameter lists, match lists include literals. Match lists also include syntactic structure not seen in the other binding structures.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/NNZ67OMA... of Conduct: http://python.org/psf/codeofconduct/