Complimentary != Complementary On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky <pmis...@gmail.com> wrote:
> Hello, > > As was mentioned many times on the list, PEP634-PEP636 are thoroughly > prepared and good materials, many thanks to their authors. PEP635 > "Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/) > stands out among the 3 however: while reading it, chances that you'll > get a feeling of "residue", accumulating a section over section. By the > end of reading, you may get a well-formed feeling that you've read a > half-technical, half-marketing material, which is intended to "sell" a > particular idea among many other very viable ideas, by shoehorning some > concepts, downplaying other ideas, and at the same time, light-heartedly > presenting drawbacks of its subject one. > > Just to give one example, literally at the very beginning, at the > "Pattern Matching and OO" section (3rd heading) it says: > > > Pattern matching is complimentary to the object-oriented paradigm. > > It's not until the very end of document, in the "History and Context" it > tells the whole truth: > > > With its emphasis on abstraction and encapsulation, object-oriented > > programming posed a serious challenge to pattern matching. > > You may wonder how "complimentary" and "posed a serious challenge" > relate to each other. While they're definitely not contradictory, > starting the document with light-hearted "complimentary" can be seen as > trying to set the stage where readers don't pay enough attention to the > problem. And it kinda worked: only now [1] wider community discovers the > implications of "Class Patterns" choices. (As a note, PEP635 does well > on explaining them, and I'm personally sold on that, but it's *tough* > choice, not the *obvious* choice). > > There're many more examples like that in the PEP635, would take too > much space to list them all. However, PEP635 refers to the paper: > > > Kohn et al., Dynamic Pattern Matching with Python > > https://doi.org/10.1145/3426422.3426983 (Accepted by DLS 2020. The > > link will go live after Nov. 17; a preview PDF can be obtained from > > the first author.) > > As that citation suggests, the paper is not directly linked from the > PEP635. But the preprint is now accessible from the conference page, > https://conf.researchr.org/home/dls-2020?#event-overview (direct link > as of now: https://gvanrossum.github.io//docs/PyPatternMatching.pdf). > > That paper is written at much higher academic standard, and a pleasure > to read. I recommend it to everyone who read PEP635 (note that it was > written with PEP622 in mind, but conceptual differences are minor). With > it, I noticed just 2 obvious issues: > > > Section 4.3. Named Constants > > > It would clearly be desirable to allow named constants in patterns > > as a replacement and extension of literals. However, Python has no > > concept of a constant, i.e. all variables are mutable (even where > > the values themselves are immutable). > > So, unlike PEP635, the paper pinpoints right the root of PEP634's > problems: lack of constants in Python (on the language level). This is > just the point which was raised on the mailing list either > ( > https://mail.python.org/archives/list/python-dev@python.org/message/WV2UA4AKXN5PCDCSTWIUHID25QWZTGMS/ > ). > > Under strict academic peer review, the paper would have been returned > for elaboration, with a note like: "Given that nowadays many dynamic > languages (PHP, JavaScript, Lua, etc.) have support for constants, and > lack of constants poses a serious usability challenge to your proposal, > please explain why you chose to proceed anyway (and apply workarounds), > instead of first introducing the concept of constants to the language. > (Given that amount of work to implement pattern matching is certainly > an order of magnitude larger than to introduce constants)." > > But the paper wasn't returned for elaboration, so we'll keep wondering > why the authors chose such a backward process. > > > Section 6.1. Scope > > > The granularity of the scope of local variables is at the level of > > functions and frames. [...] > > The only way to restrict the scope of a variable to part of a > > function’s body (such as a case clause) would be to actively delete > > the variable when leaving the block. This would, however, not restore > > any previous value of a local variable in the function’s scope. > > This is a misconception ("the only way") which is repeated almost one > to one on PEP635 either. If anything, the above describes how > pseudo-scoping is currently implemented for exception vars in "except > Exception as e:" clause (more info: > https://mail.python.org/pipermail/python-dev/2019-January/155991.html), > which is hardly a "best practice", and definitely not the only way. > > How to support multiple variable scopes in one stack frame is not a > rocket science at all. One just need to remember how C did that since > ~forever. And that's: (for unoptimized programs) variables in different > scopes live in disjoint subsections of a frame. (For optimized > programs, variables with disjoint liveness can share the same > locations in a frame). > > The only reasons for not implementing the same solution in Python would > be intertia of thought and "but it's not done anywhere else in > Python". Yeah, but nobody del'eted local variables behind users' backs > either, before somebody started to do that for exception clause > variables. And the whole of pattern matching is such that either one > thing, or another, but will be done for the first time in Python. For > example, nobody before could imagine that one can write "Point(x, y)", > and get x and y assigned, and now we're facing just that [1]. (Again, > I personally love it, though think that "Point(>x, >y)" is an > interesting option to address the tensions). > > > In that regard, the current PEP634 and friends miss too many interesting > and useful opportunities (constants in language core and true scoping > for match'es, to name a few). Well, that happens. But they try to > shoehorn too much of "we didn't do" into "it's not possible" or "it > doesn't make sense", or "let's workaround it in adhoc ways" and that > raises eyebrows, leading to concerns of whether the proposals are > actually "raw" as of yet. > > > > [1] People expressing surprise at "Class Patterns" syntax: > > https://mail.python.org/archives/list/python-dev@python.org/message/F66J72JUEAUKBM5VDSMG4HRHUEQBWI5M/ > > https://mail.python.org/archives/list/python-dev@python.org/message/Q2ARJULLJG6HRCDXR4SSA7K6NLTOPUL7/ > > > -- > 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/EQX6GK7CZVW5NS42VYJKQ3WOPEXPU5CD/ > 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/D3OMNLLAWKGBD7YWGVO7W3NR3FVJNVCI/ Code of Conduct: http://python.org/psf/codeofconduct/
