Complimentary != Complementary

On Sun, Nov 15, 2020, 4:51 AM Paul Sokolovsky <> 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" (
> 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
> > (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,
> (direct link
> as of now:
> 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
> (
> ).
> 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:
> 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:
> --
> Best regards,
>  Paul                
> _______________________________________________
> Python-Dev mailing list --
> To unsubscribe send an email to
> Message archived at
> Code of Conduct:
Python-Dev mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Reply via email to