[Python-Dev] Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
Thread information
[Search the python-dev archive]
Paul Sokolovsky [this message] ` [Python-Dev] " Steven D'Aprano ` Paul Sokolovsky ` Steven D'Aprano ` [Python-Dev] constants in Python: Starting simple and gradually adding more features, was: Re: Pattern Matching controversy Paul Sokolovsky ` [Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead Jim J. Jewett ` Tobias Kohn ` Paul Sokolovsky ` David Mertz ` MRAB ` Paul Sokolovsky ` Greg Ewing ` Paul Sokolovsky ` Steven D'Aprano ` Paul Sokolovsky ` Stephen J. Turnbull ` Paul Sokolovsky ` Stephen J. Turnbull ` Paul Sokolovsky ` Stephen J. Turnbull ` Guido van Rossum ` Andrew Svetlov ` Paul Sokolovsky ` Steven D'Aprano
From: | Paul Sokolovsky <pmiscml-AT-gmail.com> | |
To: | Python-Dev <python-dev-AT-python.org>, Tobias Kohn <kohnt-AT-tobiaskohn.ch>, "Brandt Bucher" <brandtbucher-AT-gmail.com> | |
Subject: | [Python-Dev] Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead | |
Date: | Sun, 15 Nov 2020 12:48:50 +0300 | |
Message-ID: | <20201115124850.707a1caf@zenbook> |
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.o...). 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...), 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.o... https://mail.python.org/archives/list/python-dev@python.o... -- Best regards, Paul mailto:pmiscml@gmail.com _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.... Message archived at https://mail.python.org/archives/list/python-dev@python.o... Code of Conduct: http://python.org/psf/codeofconduct/