Hello, On Sun, 7 Feb 2021 04:53:43 +0300 Ivan Pozdeev <v...@mail.mipt.ru> wrote:
> On 07.02.2021 0:24, Paul Sokolovsky wrote: > > Hello, > > > > On Sun, 7 Feb 2021 00:00:41 +0300 > > Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote: > > > >> Who said "__future__"? > > Other people said __future__. And yet other said "it's ok the way it > > is, it's better to have it like that then keep not having it". And > > yet other said something else (multiple else's). > > > >> 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. > > Such libraries exist for decade(s). MacroPy is a venerable, > > well-known macro-capabilities-for-Python solution, which offers a > > kind of pattern matching: > > https://macropy3.readthedocs.io/en/latest/pattern.html . There're a > > bunch of other, grep github. > > > > https://github.com/MegaIng/syntax-extensions-pep634 specifically > > advertises itself as pure-Python implementation of PEP634 (using a > > newer macro library), though I'm not sure how well it's development. > > It also of course represents the right way to develop Python - in > > Python itself. Sadly, "C" in "CPython" is stuck too deep in many > > minds... > > > > > > Bottom line is however: given the decade(s) old history of pattern > > matching in *Python* (usual warning: don't mix up Python and > > CPython!), arguing that very resourceful attempt to add pattern > > matching to the reference implementation (that's where *CPython* > > finally pops up), should be flushed down the toilet and the Python > > community should be brought back into decade-long waiting state > > without a reference implementation for pattern matching - umm, > > suggesting that doesn't seem to be very productive. > > That's not the impression I got from looking through the discussiuon > and the PEP. I pretty closely followed "second half" of patter matching discussion - after it became clear that there're a lot of criticism (and I shared some criticism too). And I've got somewhat different impression than yours. > I don't see references to any of those existing implementations > anywhere in the PEP as well as a summary of various existing > approaches and solutions, their pros and cons etc. which the proposal > proper would derive its particulars from. Well, a PEP is not "annals of Python history as related to area XXX". It's a proposal for a specific change. Which should have good argumentation, but still doesn't have to start with "When the Earth was ball of flame, ...". There can be "too much" too. You can see that very well with pattern matching proposal: its started as PEP622, but was deemed too long and wide-scoped, and split into *three* of PEP634/PEP635/PEP636 - all to ease community review. There was also a proposal to add "other possible options" to PEP622, which was rejected, and spawned into separate PEP642. So, there quite a work was done, and saying "it's not enough" is not helpful and not appreciating of authors' efforts (pretty titanic efforts from mere Python user PoV). > Both the PEPs and the > discussion look like they are trying to write the functionality > completely from sctratch, by the seat of their pants. The authors of the PEPs are definitely aware of pre-history of pattern matching in Python. Heck, that's why they went ahead with their proposal - because they know that people wanted pattern matching in Python for decades! Designing "completely from scratch" isn't a bad choice in situation with multiple choices and complex enough systems. And it wasn't "completely from scratch", on multiple occasions authors said "that's done similar to pattern matching in other languages". Authors of alternative patmatching impls also provided feedback (I'm not sure how well that was heard). > And from how much discord there is about syntax and semantics, And that's where my impressions differ. There's a strong sentiment that various aspects of pattern matching could "easily" be made better right from the start than described in PEP634/PEP635/PEP636. But from people who're interested in pattern matching, there're hardly valuation like "PEP634 is so bad that we'd rather punish ourselves and live without it, than with PEP634". If anything, PEP642 showed that things can be much worse. And it's ironic, because it exactly started with "small obvious improvements to PEP634", but decided to replay the "road to hell is paved with good intentions" proverb, and from small obvious things went to pretty tangled speculations. > I conclude that these are far from being well-established and > practice-proven. So if the existing solutions really have a > "decades-long history" as you claim, that history must be > spectacularly uneventful -- which suggests that the feature is either > in low demand or was ultimately proven by practice to be inadequate > for real-world use. Let me continue the story of MacroPy. His authors barely maintains it. Because for many years his primary language is Scala. That's not exception, but a very visible pattern - many advanced Python users end not being Python users. And we're end with the community of "Pattern matching? Never heard." Don't trust such voices. Trust voices of people who use multiple languages, but *still* return to Python to make it better ("better"? to "stand well against other languages" is a better term). PEP634 was written by such people. It's pretty ungrateful to suggest that Python doesn't need their effort, among the situation when pattern matching is becoming the norm in the programming language space. -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ 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/TPYEAQZUWI32IQHNBT6EKE2TBEXQOCT2/ Code of Conduct: http://python.org/psf/codeofconduct/
