On Mon, Nov 16, 2020 at 6:41 AM Mark Shannon <m...@hotpy.org> wrote: > I believe that a pattern matching implementation must have the following > properties: > > * The semantics must be precisely defined. > * It must be implemented efficiently. > * Failed matches must not pollute the enclosing namespace. > * Objects should be able determine which patterns they match. > * It should be able to handle erroneous patterns, beyond just syntax > errors. > > PEP 634 and PEP 642 don't have *any* of these properties. >
Mark, I trust that those are your beliefs. But your words are just sufficiently vague that anyone can read into them what they want. (IOW, the semantics of your words are not precisely defined. :-) 1. When drafting PEP 634, I spent a *lot* of time making the description of the semantics as clear and precise as they could be, using carefully defined terms like matching, subpattern, binding and so on. The syntax of patterns is defined recursively, and so are the semantics. If you have specific concerns about ambiguities in the description, please quote the relevant text of the PEP and ask what the intention is or just suggest an improvement. Otherwise I cannot do anything with your claim "the PEP does not describe the semantics precisely" except disagreeing. Note that specifying semantics in terms of a translation to "equivalent" Python code is also fraught with difficulties, and is in danger of over-specifying irrelevant details. 2. Regarding efficient implementation, I would phrase it differently. I think that it must be *possible* to implement it efficiently. During the design phase we spent a lot of time thinking about the implementation, and the specification leaves plenty of room for improving upon Brandt's initial implementation. Your demand that the initial implementation be "efficient" is baseless, and your claim that the reference implementation isn't sufficiently efficient is insulting to Brandt. I also see no reason to believe it. Historically, everything in Python starts out relatively inefficient and over time we speed up those parts of the implementation that need it. 3. Your claim "Failed matches must not pollute the enclosing namespace" is entirely subjective. Since succeeding matches store captured values in the enclosing namespace, those variables that may be overwritten by the matching process are liable to be overwritten anyway. I've seen your counter-proposals for this (both save/restore and $-number variables), and I won't object if you implement something like that after the initial implementation lands, but I *would* object if I couldn't enter e.g. set a breakpoint on a guard expression in a debugger and inspect the capture variables using their regular names. I don't see your statement as a requirement for an initial implementation, and I think the compiler will be simpler without it. 4. "Objects should be able [to] determine which patterns they match" is again a subjective claim. We debated adding a `__match__` method to objects to enable this but couldn't get agreement on how it should be called and what it should return. We even came up with a proposal that made it into the first draft of PEP 622, after a long debate about the efficiency of the interface. But in the end it added complexity and we didn't have any sufficiently strong use cases, so we decided that we would punt on this one. This is the kind of thing that can easily be added in a future revision without breaking backwards compatibility, so we took it out to limit the scope of the proposal. 5. Your bullet about erroneous patterns seems to be meant to call out one particular quirk of the proposal, which is that class patterns can specify as keywords anything that is a valid attribute, which includes for example methods. My attitude towards this can be characterized as "so what?" It has already been pointed out that the same mistake can occur in non-pattern-matching code (e.g. `if nt.count == 1`), and I don't think this kind of mistake is going to be any more prevalent in class patterns than it is in other code. Finally, recalling your past comments on PEP 622, PEP 634, and other PEPs, I feel hurt by the apparent disrespect you express for the authors and their designs (the current thread being just one example). If I compare Larry Hastings' post to discourse <https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770/21> where he explains that he doesn't want pattern matching I see none of that, but in your posts it shines through again and again. Can I ask you to please take a step back and think about why this may be, and try to change something in your writing style? We all will need to get along for a long time after this particular topic is put to rest, but each time I see one of your posts like this I find it harder to respond rationally rather than emotionally. (It is no accident that it took me 5 days to respond here.) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/5UPCID362PB3JUKL636OJR63IYEAQ4TY/ Code of Conduct: http://python.org/psf/codeofconduct/
