My suggestion that it be introduced via __future__ due to its contentious nature met immediate resistance. No point going down that road.
Kind regards, Steve On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > With such a large new area of functionality that's at odds with existing > syntax and semantics and a lack of clear vision and agreement, it > sounds like this would be better first added as a 3rd-party library to let > the syntax and semantics mature. (To allow new syntax, it'll > probably be parsing strings in that special syntax.) > > (At https://www.python.org/dev/peps/pep-0634/, there's no indication that > this option was considered.) > > On 06.02.2021 18:44, Mark Shannon 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? > > > > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods > to the object model, and that works very well. > > > > > > 2. PEP 634 deliberately introduces a large area of undefined behaviour > into Python. > > > > > https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior > > > > Python has, in general, been strict about not having undefined behaviour. > > Having defined semantics means that you can reason about programs, even > non-idiomatic ones. > > [This is not unique to Python, it is really only C and C++ that have > areas of undefined behaviour] > > > > I can see no good reason for adding undefined behaviour. It doesn't help > anyone. > > > > The lack of precise semantics makes programs harder to understand, and > it makes the language harder to implement. > > If the semantics aren't specified, then the implementation becomes the > specification. > > This bakes bugs into the language and makes it harder to maintain, > > as bug-for-bug compatibility must be maintained. > > > > > > 3. Performance > > > > PEP 634 says that each pattern must be checked in turn. > > That means that multiple redundant checks must be performed on (for > example) a sequence if there are several mapping patterns. > > This is unnecessarily slow. > > > > > > Implementation > > -------------- > > > > My main concern with the implementation is that it does too much work > into the interpreter. > > Much of that work can and should be done in the compiler. > > For example, deep in the implementation of the MATCH_CLASS instruction > is the following comment: > > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981 > > > > Such complex control flow should be handled during compilation, rather > than in the interpreter. > > Giant instructions like MATCH_CLASS are likely to have odd corner cases, > > and may well have a negative impact on the performance of the rest of > the language. > > It is a lot easier to reason about a sequence of simple bytecodes, than > one giant one with context-dependent behaviour. > > > > We have spent quite a lot of effort over the last few years streamlining > the interpreter. > > Adding these extremely complex instructions would be a big backward step. > > > > > > Cheers, > > Mark. > > _______________________________________________ > > 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/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > Regards, > Ivan > _______________________________________________ > 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/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/DJJLEMZ7I5Q5HWR5VMNMPPMEGRVAQSUU/ Code of Conduct: http://python.org/psf/codeofconduct/
