On Sat, 6 Feb 2021 at 19:54, Daniel Moisset <dfmois...@gmail.com> wrote: > > Hi Mark, > > I think some of these issues have already been raised and replied (even if no > agreement has been reached). but this is a good summary, so let me reply with > a summary of responses for this. > > On Sat, 6 Feb 2021 at 15:51, Mark Shannon <m...@hotpy.org> wrote: >> >> Hi, >> >> Since a decision on PEP 634 is imminent, I'd like to reiterate some >> concerns that I voiced last year. >> >> I am worried about the semantics and implementation of PEP 634. >> I don't want to comment on the merits of pattern matching in general, or >> the proposed syntax in PEP 634 (or PEP 640 or PEP 642). >> >> Semantics >> --------- >> >> 1. PEP 634 eschews the object model, in favour of adhoc instance checks, >> length checks and attribute accesses. >> >> This is in contrast to almost all of the the rest of the language, which >> uses special (dunder) methods: >> All operators, >> subscripting, >> attribute lookup, >> iteration, >> calls, >> tests, >> object creation, >> conversions, >> and the with statement >> >> AFAICT, no justification is given for this. >> Why can't pattern matching use the object model? > > > No one has said that "we can't". It's just that "we don't have to". The > underlying mechanisms used by pattern matching (instance check, length, > attribute access) already have their defined protocols and support within the > object model. It's analogous as the way in which iterable unpacking didn't > need to define it's own object model special methods, because the existing > iteration mechanism used in for loops was sufficient. > > This does not exclude possible future extensions to the object model to > include a richer protocol like described in > https://www.python.org/dev/peps/pep-0622/#custom-matching-protocol (where it > also describes why we're not proposing that *now*, why it can be done later, > and why we think it's best to do it later)
I find that particular section of the PEP unsatisfying. The illustrated protocol seems to be much more complex than anything I would have imagined. The thing that I find jarring about this PEP is that it seems to make positional arguments second class to keyword arguments and attributes at the same time as suggesting an equivalence that doesn't really exist between keyword arguments and attributes. I raised something related previously: https://mail.python.org/archives/list/python-dev@python.org/thread/V6UC7QEG4WLQY6JBC4MEIK5UGF7X2GSD/ If I have a class that takes positional arguments like p = Point2D(x, y) (example from the PEP) then in order to match it I have to define attributes for x and y and the matcher will use p.x and p.y to match against the "arguments" in `case Point2D(a, b)`. The PEP proposes to use __match_args__ == ['x', 'y'] in order to translate the argument positions 0 and 1 (of a and b) into attributes x and y and then use getattr to compare them in the matching protocol. It is very likely though that the Point2D class can efficiently return a tuple of positional arguments like (x, y) that could be compared more directly against (a, b) without any need for *attributes* to be involved. I would have expected that __match_args__ would be used in reverse to the way the PEP proposes: to translate keyword arguments from the pattern to positional arguments on the object rather than positional arguments in the pattern to attributes on the object. The PEP says: > Late in the design process, however, it was realized that the need for a > custom matching protocol was much less than anticipated. Virtually all the > realistic (as opposed to fanciful) uses cases brought up could be handled by > the built-in matching behavior, although in a few cases an extra guard > condition was required to get the desired effect. The PEP introduces many special cases for builtin types rather than a general extensible mechanism that can work for builtin types as well as user-defined types. That means it can handle various common cases but misses out on others. Referring to the thread I linked above mentioning sympy if I have a class like Add with instances like Add(x, y, z), Add(x, y, z, t) etc. It would seem very natural to me that I should be able to match against that but it isn't possible to do that directly because there is no way in PEP 622 to handle variadic arguments when matching against a user defined class. The PEP makes it possible to match variadic-ish "arguments" with builtins like tuple, list, etc but that is done with special casing rather than with a protocol that can be applied equally to user defined types. Personally I would be happier with the PEP if it had a clear protocol such that builtin types could support the protocol in an efficient and natural way. If a protocol works well for builtin types then that suggests that it can work well in general. If the only way to make this work for builtin types is to give them special-case support then that points to a deficiency in the protocol. -- Oscar _______________________________________________ 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/MBQT2FFZVFKM63JARP2MLDYUGHVNKQWL/ Code of Conduct: http://python.org/psf/codeofconduct/
