Good luck in your quest. Kind regards, Steve
On Sat, Feb 6, 2021 at 9:00 PM Ivan Pozdeev <v...@mail.mipt.ru> wrote: > Who said "__future__"? I said "3rd-party library". Independent from the > CPython project. > Maybe even a few of them -- to try out conflicting visions that emerged in > the discussions. > On 06.02.2021 23:58, Steve Holden wrote: > > 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/ >> > -- > 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/4JJJEK6SKOIQMKMC7PYURQ3N6RJYG5CG/ Code of Conduct: http://python.org/psf/codeofconduct/
