I've built the reference implementation and I'm experimenting with the
new syntax in the edgedb codebase. It seems to have plenty of places
where pattern matching adds clarity. I'll see if I find particularly
interesting examples of that to share.
So far I'm +1 on the proposal, and I like the second iteration of it.
Except that I'm really sad to see the __match__ protocol gone.
It will be back, just not in 3.10. We need more experience with how match/case are actually used to design the right `__match__` protocol.
Quoting the PEP:
> One drawback of this protocol is that the arguments to __match__ would be expensive to construct, and could not be pre-computed due to the fact that, because of the way names are bound, there are no real constants in Python.
Note: That's not referring to the `__match__` protocol from version 1 of the PEP, but to a hypothetical (and IMO sub-optimal) `__match__` protocol that was discussed among the authors prior to settling on the protocol from version 1.
While it's not possible to precompute the arguments ahead of time, it
certainly should be possible to cache them similarly to how I
implemented global names lookup cache in CPython. That should
alleviate this particular performance consideration entirely.
Where's that global names lookup cache? I seem to have missed its introduction. (Unless you meant PEP 567?)
Having __match__ would allow some really interesting use cases. For
example, for binary protocol parsers it would be possible to replicate
erlang approach, e.g.:
match buffer:
case Frame(char('X'), len := UInt32(), flags := Bits(0, 1, flag1,
flag2, 1, 1))
would match a Frame of message type 'X', capture its length, and
extract two bit flags. This perhaps isn't the greatest example of how
a full matching protocol could be used, but it's something that I
personally wanted to implement.
I see, you'd want the *types* of the arguments to be passed into `Frame.__match__`. That's interesting, although I have a feeling that if I had a real use case like this I'd probably be able to come up with a better DSL for specifying messages than this.