On Fri, Jul 17, 2020 at 3:54 PM Guido van Rossum <gu...@python.org> wrote: > > On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov <yselivanov...@gmail.com> > wrote: >> >> 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.
Makes sense. > >> >> 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?) Here are the related bpos of where Inada-san and I worked on this: https://bugs.python.org/issue28158 https://bugs.python.org/issue26219 > >> >> 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. Yeah, it's an open question if this is a good idea or not. FWIW here's a relevant quick erlang tutorial: https://dev.to/l1x/matching-binary-patterns-11kh that shows what it looks like in erlang (albeit the syntax is completely alien to Python). Yury _______________________________________________ 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/LMWGQX4RNZE2WS34OM6QU7SLFVQIKYT3/ Code of Conduct: http://python.org/psf/codeofconduct/
