On Sat, Feb 6, 2021 at 6:04 PM Steve Holden <st...@holdenweb.com> wrote: > > My suggestion that it be introduced via __future__ due to its contentious > nature met immediate resistance. No point going down that road.
This is really unfortunate. I agree this is a huge language change and it should only be approved with some mechanism requiring explicit opt-in (such as __future__ import) AND it should be documented as provisional for several releases, like asyncio was (and remember: the asyncio API had lots of breaking changes and prompted the addition of the async/await keywords, a great improvement that forced the renaming of the very fundamental async function from the original API). Scala is recognized as an overly complex language [1], in part because the designers like to experiment with new features all the time. It's not a great benchmark for Python IMHO, but if we are going to leverage the new PEG parser with huge language choices changes more often than we have in the past, then we should consider adopting the feature toggles like the Scala compiler [2], so that individual teams can decide which features they want to use and which they don't. [1] https://www.thoughtworks.com/radar/languages-and-frameworks/scala-the-good-parts [2] https://docs.scala-lang.org/overviews/compiler-options/index.html (look for options with the -language prefix) Cheers, Luciano > > 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/ -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg _______________________________________________ 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/X3CCXMD7VANWPT7VHKQSZ6C5CVZLMJE3/ Code of Conduct: http://python.org/psf/codeofconduct/
