[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
Hello, On Sun, 15 Nov 2020 00:22:01 -0500 Kyle Stanley wrote: [] > FWIW, I'd like to add my +1 to usage of "as" for spelling class > capture patterns. If you want to use "as" in spelling of class capture patterns, you don't need to worry about anything, because PEP634 already allows that: case Point(x=_ as a, y=_ as b): (better spelled as: case Point(x = _ as a, y = _ as b): ) You need to worry only if: 1. You find that the "as" form is too verbose, and strongly believe that the same expressive means can be achieved in more concise syntax. 2. If you worry that other people will still write "case Point(x=a, y=b)" and that will confuse you and/or yet other people. For p.2, combination of p.1 and switching default syntax to be value patterns offers an interesting solution. (Solution to force everyone to write long verbose "as" patterns, or ambiguous "as" patterns, aren't "interesting" IMHO). -- 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/37ZOGLGGBPBHVPWXOPYQFS52BENL4L5H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
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 "
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote: > Just to give one example, literally at the very beginning, at the > "Pattern Matching and OO" section (3rd heading) it says: If it's the third heading, it's not *literally* at the very beginning. > > 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. There's no need to wonder. Just keep reading: "In short: in object-oriented programming, we can no longer view objects as tagged tuples. The arguments passed into the constructor do not necessarily specify the attributes or fields of the objects. Moreover, there is no longer a strict ordering of an object's fields and some of the fields might be private and thus inaccessible. And on top of this, the given object might actually be an instance of a subclass with slightly different structure. To address this challenge, patterns became increasingly independent of the original tuple constructors." The challenge was not, as you imply, that OOP was a challenger to pattern matching by offering an alternative idiom that made pattern matching obsolete. The challenge was to update pattern matching implementations to work with objects that don't map well to tagged tuples. [...] > 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). It would be nice to have the PEP link to the paper. I found it very useful for my understanding to compare how other languages solved or avoiding these issues. I disagree strongly with your further points about Named Constants and Scopes. I think you make unjustified, and mostly likely wrong, statements like: > Under strict academic peer review, the paper would have been returned > for elaboration, > amount of work to implement pattern matching is certainly an order of > magnitude larger than to introduce constants > The only reasons for not implementing the same solution [block scopes] > in Python would be intertia of thought and "but it's not done anywhere > else in Python". but in an effort to try to keep matters focused, I won't elaborate. Having said that, I would like to see some discussion on what it would take to bring in constants to the language in a fully backwards compatible fashion, without hurting performance. Perhaps it is as easy as you say, perhaps not. If it is easy, that might work for pattern matching. It is isn't easy, it would be nice to know why. Here's a toy proposal, not intended to be taken too seriously: for local constants, inside a function, the compiler could detect and reject (with a SyntaxError) more than one attempt to bind a value to a name declared as constant, with no runtime cost. Outside of functions, we could add one extra scope between locals and globals, a "const" scope, which implements write-once semantics. This would make every global and builtin name lookup more costly. Looking at the paper, I like the look of Elixer's pin operator: case ^mylib.STATUS_OK, result: would match mylib.STATUS_OK by value, without binding, and capture result. I think that's better than the PEP's current DWIM (Do What I Mean) approach that a dotted identifier must be a constant and an undotted identifier is a capture pattern. On the other hand, I can see myself forgetting the pin and accidentally binding to (pseudo-)constants: case mylib.STATUS_OK, result: would accidentally replace the STATUS_OK code. Ouch. Maybe we should flip the meaning of pin and have it mark capture patterns? case mylib.STATUS_OK, ^result: Here if I forgot the pin, I'd likely get a NameError. -- Steve ___ 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/FFHRMEBIXGYCWXSYH52QHD76O7MWZQDW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote: > But Point(x as a) already has a meaning in PEP 634; it’s a positional > argument captured in x *and* in a. (Previously spelled as Point(a := x). > The phrase ‘as a’ can be added after any pattern to *also* capture it in > ‘a’. More typically used as e.g.‘Pattern(x, y) as p’, which captures the > first two fields in x and y, and the whole Point in p. > Indeed, the proposed change I'm contemplating for class matching would require that positional matching be opt-in rather than the default. The default would instead become to check that the named attributes exist, so "Pattern(x, y)" would be short for "Pattern(x=__, y=__)", and you'd have to write "Pattern(x, y, /)" instead to request positional arg matching. The default behaviour of class patterns would become a lot more like mapping patterns, but working off attribute names rather than keys. I think that will give an end result that offers the same capabilities as PEP 634, but the proof will be in the reference implementation update. Cheers, Nick. > ___ 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/Y2PDB76J5YHO7GWXLIYXGEL4MSXUT7RT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
Hello,
On Sun, 15 Nov 2020 22:05:46 +1100
Steven D'Aprano wrote:
> On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote:
>
> > Just to give one example, literally at the very beginning, at the
> > "Pattern Matching and OO" section (3rd heading) it says:
>
> If it's the third heading, it's not *literally* at the very beginning.
Thanks for stopping by that. 3rd of 26, but yeah, "beginning-ness is in
the eye of beholder".
[]
> > You may wonder how "complimentary" and "posed a serious challenge"
> > relate to each other.
>
> There's no need to wonder. Just keep reading:
I read it in full, and explained my concerns with the wording (of
PEP625 in general): is seems to be carefully chosen to lead the reader
to believe that the view presented in PEP634 is the only viable choice,
and to downplay other alternatives (too much, and unfairly).
[]
> > https://gvanrossum.github.io//docs/PyPatternMatching.pdf).
>
> It would be nice to have the PEP link to the paper. I found it very
> useful for my understanding to compare how other languages solved or
> avoiding these issues.
>
>
>
> I disagree strongly with your further points about Named Constants
> and Scopes. I think you make unjustified, and mostly likely wrong,
> statements like:
>
> > Under strict academic peer review, the paper would have been
> > returned for elaboration,
Well, this is not a statement, but a speculation, based on reading many
complaints from (usually junior) researches of how it's hard to get a
paper published/conf-accepted when a subject concern improvement to an
existing technique - there're oftentimes multiple rounds of rejections
with suggestions to prove the point that it's indeed "improvement" and
how it compares to actual and possible alternatives.
> > amount of work to implement pattern matching is certainly an order
> > of magnitude larger than to introduce constants
>
> > The only reasons for not implementing the same solution [block
> > scopes] in Python would be intertia of thought and "but it's not
> > done anywhere else in Python".
By these two I stand, yeah. (And ready to be proven wrong, be ashamed,
and learn from it.)
> but in an effort to try to keep matters focused, I won't elaborate.
>
> Having said that, I would like to see some discussion on what it
> would take to bring in constants to the language in a fully backwards
> compatible fashion, without hurting performance. Perhaps it is as
> easy as you say, perhaps not. If it is easy, that might work for
> pattern matching. It is isn't easy, it would be nice to know why.
Thanks, that's exactly what I'd like to see too. And while it was
pointed previously that this is orthogonal matter to pattern matching,
the common sense keeps kicking in, suggesting that it's a *prerequisite*
to having non-adhoc pattern matching design.
> Here's a toy proposal,
[]
The baseline of my version is much simpler:
# This makes "const" a kind of hard keyword for this module
from __future__ import const
FOO: const = 1 # obviously, this is constant
Foo_Bar: const = 2 # this is too
foo: const = 3 # and like it or not, but this is constant either
"const" annotation is recognized by compiler (scope resolving
component, aka symtable builder to be exact) as a property orthogonal to
localness/globalness. Literally, "symtable" module
(https://docs.python.org/3/library/symtable.html#symtable.Symbol) will
grow Symbol.is_const() method.
The rest should be clear - if there's:
case sym:
Where Symbol.is_const() is true for "sym", then value of that symbol
is used for matching (instead of treating it as a binding target).
This definitely would be very beginning of const's journey in Python,
but exactly the amount needed to address concerns with "force enum
usage" adhockery in PEP634.
[]
> Looking at the paper, I like the look of Elixer's pin operator:
>
> case ^mylib.STATUS_OK, result:
And I don't. I think that "==", as used in PEP642v2, much better fits
with Python syntax and overall feel (that's also what you and I
suggested, before PEP642v2 picked it up, right?).
But again, the whole idea to introduce const's is to drop the need for
any "pin operator" in 90% of cases, when constants are used. "Pin
operator" will be needed only to match against a real variable:
FOO: const = 1
BAR: const = 2
i_dont_know_yet = FOO if sth() else BAR
match a:
case == i_dont_know_yet:
print("We're better than Rust")
[]
>
> Maybe we should flip the meaning of pin and have it mark capture
> patterns?
>
> case mylib.STATUS_OK, ^result:
But that's the humble idea, the epiphany of which I humbly spread around
for a month (as an alternative to both const-introduction (we won't
get around that!) or "=="-marking). Except that you used the wrong arrow
- it shouldn't point away from capturing variable, but right into the
heart of it:
case mylib.STATUS_OK, >result:
case mylib.STATUS_OK, >>result:
case mylib.STATUS_OK, ->result:
- al
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
Hi Paul, Thank you for your comments on the DLS'20 paper. I am glad to hear that it helps paint a clear(er) picture of pattern matching in Python. However, please let me set the record straight in a few regards. First, there is no 'shoehorning' or 'deception' in our pattern matching PEPs. This notion of our team standing against the Python community or trying to outsmart it is quite absurd and unnecessary, really. At the end of the day, you might find that the PEPs are a boiled-down version of months of intense work and discussions (as Brandt has already pointed out elsewhere) and thus necessarily terse in some parts. Pattern matching is a complex subject and the PEPs have been written with a sincere effort to convey the big picture and give a tour of this feature in an accessible manner. Our entire discussion is all openly available to anyone interested. Second, our work on pattern matching is based on a very simple premise/idea: *bring pattern matching to Python*. In particular, it is *not* to 'bring Python to pattern matching'. We want to introduce pattern matching as a new feature to Python as Python stands right now, without the need to first modify Python and make it more static, C-like, functional or whatever. As I have mentioned before, pattern matching is an opt-in feature, something with absolutely no influence on the behaviour of any Python program you have ever written before. Not introducing constants or a completely new kind of scopes to Python first is certainly not a lack of academic rigour, oversight on our part because we are not smart enough, or trick to coerce people into accepting pattern matching. It just means that we propose to introduce pattern matching to Python as it is right now. Third, the academic paper has a different scope than the PEPs. In case you missed it: after the first version of PEP 622, we listened to the reactions and suggestions from the community and went back to overhaul the entire design and build as much as possible on the raised concerns and cummulative experience of the community. One major outcome of this was to reduce the overall proposal to the absolute core features of what we need for pattern matching (another was to put more effort into writing an accessible account of what we propose and why we think the various design features are a good choice, leading to three PEPs with different aims). The academic paper outlines a much larger scope of possibilities than the PEPs, whereas the PEPs are more grounded in the pragmatic and taking one step at a time. In short, the academic paper lays out an entire journey, a vision, whereas the PEPs propose a first step forward. Finally, the reason why the academic paper has not been referred to before is simply that it will officially be published coming (!) week. Since the process of peer review is now complete, we can already provide a preprint. It was clear from the outset that the PEPs will contain a link to the paper as soon as it becomes publicly available. Of course, we encourage anyone interested in it to read the academic paper. Since its focus is somewhat complementary to the PEPs, it might highlight some ideas behind our design that might not be made clear enough in the PEPs. But while doing so, please keep in mind that the paper is a vision of a bigger picture and as such distinct from the PEPs! Kind regards, Tobias Quoting Paul Sokolovsky : 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 implicati
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
Hello Tobias, On Sun, 15 Nov 2020 13:22:07 +0100 Tobias Kohn wrote: > Hi Paul, > > Thank you for your comments on the DLS'20 paper. I am glad to hear > that it helps paint a clear(er) picture of pattern matching in > Python. However, please let me set the record straight in a few > regards. That's definitely true, and thanks for this reply too, as it indeed sets many point straight regarding the PEP635. I'd say that I'm on my side largely satisfied both with reading materials and responses of Brandt and yours. But we still have PEPs on the plate which raise concern from different people (not just myself), so please let me continue. > First, there is no 'shoehorning' or 'deception' Hey, I didn't use that word ;-) > in our pattern > matching PEPs. This notion of our team standing against the Python > community or trying to outsmart it is quite absurd and unnecessary, > really. At the end of the day, you might find that the PEPs are a > boiled-down version of months of intense work and discussions (as > Brandt has already pointed out elsewhere) and thus necessarily terse > in some parts. This is very good point, and I easily believe it. In an alternative universe, if there would be any bias, conscious or subconscious, it's still would be good-intentioned, for sure. For example, suppose that you, the PEP authors, thought out all choices, and found insurmountable issues with all of them, but one. Knowing that the SC would need to decide on them, it would be only naturally to present material in a way to not take their precious time with dead-ends, and present only the winning proposal. There's absolutely nothing wrong with that, I myself could do the same. The whole culprit under this point of view are exactly some people from community who continue to search for gold in a mine you know empty. The role of community is at all not clear. It's only relatively recently aspects of Python decision-making caught wide attention, with PEP572. And as we know, that was a point where decision process changed considerably either. And... we still don't know how it works in details (only learning it). Maybe it's largely a matter between PEP authors and SC, then PEPs are definitely "ok" and nothing can be improved. What concerns community has, can be seen from some posts, e.g. https://mail.python.org/archives/list/python-dev@python.org/message/IG4VNKZF4J7OR3L665PE26KL7L6SFQSQ/ (the title: "PEP 622 railroaded through?"). I'm sorry if I join this perceived "conspiracy theory". Just as that's not the intention of PEPs, neither it's the intention of feedback like that. Finding omissions (yes, after so much work on PEPs!) and hope for improvements is the intention. > Pattern matching is a complex subject and the PEPs > have been written with a sincere effort to convey the big picture > and give a tour of this feature in an accessible manner. Our entire > discussion is all openly available to anyone interested. > > Second, our work on pattern matching is based on a very simple > premise/idea: *bring pattern matching to Python*. In particular, it > is *not* to 'bring Python to pattern matching'. We want to > introduce pattern matching as a new feature to Python as Python > stands right now, without the need to first modify Python and make it > more static, C-like, functional or whatever. Makes sense, and your choice. But not entirely consistent with what you write in the paper: >> In contrast to pattern matching in other dynamic languages [3, 11], >> we implement it as a compiled feature of the language in the >> tradition of static languages [6, 22] rather than introducing >> patterns as first-class objects. Again, it's your right to stop where you see reasonable. It's the right of reviewers to point out that you stopped half-way, and even criticize such a choice. > As I have mentioned > before, pattern matching is an opt-in feature, something with > absolutely no influence on the behaviour of any Python program you > have ever written before. Another good argument I fully agree with my. I still have a counter-argument: pattern matching seems like an important and conceptually deep enough change, which could be compared to switching Python to proper lexical scoping, or switching multiple inheritance to C3 algorithm away from the adhoc one which was used before. Not done right, pattern matching risks integrity and soundness of language. > Not introducing constants or a completely > new kind of scopes to Python first is certainly not a lack of > academic rigour, oversight on our part because we are not smart > enough, or trick to coerce people into accepting pattern matching. > It just means that we propose to introduce pattern matching to Python > as it is right now. Makes sense again. And you're well aware of counter-arguments, as polar as "we don't need pattern matching in Python". You definitely do, as was a subsection in PEP622 with literal heading "Don't do this, patter
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
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" (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) variable
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
On 2020-11-15 09:48, 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" (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. That looks like a mistake to me; it should be "complementary". [snip] ___ 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/FL5VVQGGF4KQ6VCMGVFF6BM4BGCDGFKT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Configure Python initialization (PyConfig) in Python
Le sam. 14 nov. 2020 à 14:43, Nick Coghlan a écrit : > > My remaining problem is that my PR changes PyConfig_Read(): it no > > longer computes the Python Path Configuration, since it is now > > implemented in Python. IMO it's an acceptable drawback compared to the > > benefit of these new features. > > Even though I wouldn't expect it to be controversial, it's probably > worth writing up this migration of the path configuration code from C > to Python as a PEP, along the lines of what we suggested in the last > part of the PEP 432 withdrawal notice. > > The change has the potential to produce unexpected consequences for > folks inadvertently relying on the quirks of the current > implementation, and having the PEP there to cover the technical > details means we can provide more information than could be squeezed > into a single paragraph in the What's New document. I agree that a PEP would be a good way to communicate the rationale and the API changes. I have to think about it ;-) The tricky part is always the backward compatibility part, since this change is clearly backward incompatible on purpose. Since it's a "new" API (Python 3.8, released in October 2019), maybe it would be acceptable. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/X45X2K4PICTDJQYK3YPRPR22IGT2CDXB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Steering Council Election Timeline for 2021 term
Reminder: the deadline for nomination is tonight, hurry up ;-) Current candidates can be found at: https://discuss.python.org/c/core-dev/steering-council-nominations/21 Victor Le mer. 28 oct. 2020 à 20:55, Ewa Jodlowska a écrit : > > Hi! > > The timeline for this year's election will be the same as last year. > > * The nomination period will begin Nov 1, 2020 (do not post nominations until > then) > * Nomination period will end Nov 15, 2020 > * Voting will begin Dec 1, 2020 > * Voting will end Dec 15, 2020 > > Nominations will be collected via https://discuss.python.org/ (more details > to follow on Nov 1). > > New for this year: Ernest W. Durbin III will be running the vote along with > the assistance of Joe Carey, a PSF employee. They will be co-admins going > forward. I have cc'ed them in on this thread as well in case there are any > questions. > > Thanks, > > Ewa > > ___ > python-committers mailing list -- python-committ...@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committ...@python.org/message/JHYSU6FEYM3A5AZXSICO5OE3VAWDPGEJ/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/LTAY635DKLMR2655CQN2S5Z7YBILDF24/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
Hello, On Sun, 15 Nov 2020 16:58:09 + MRAB wrote: [] > >> Pattern matching is complimentary to the object-oriented > >> paradigm. > > > That looks like a mistake to me; it should be "complementary". This way or that, my point is that even the word "orthogonal" wouldn't give it fairness in that context. It should have gone straight to "conflicting", to raise the alertness level to the somewhat-hard on the perception matters which (eventually, a dozen or so headings below) follow. Then maybe there wouldn't be surprises several months later like "Oh really, 'case Point(x=a, y=b):' assigns to a and b??77" (Only maybe, perception is hard thing to play with. Though I truly believe that people would pick it up subconsciously quickly enough, after making a few mistakes. Then again, that's why I propose for consideration an option to write it `case Point(x = >a, y = >b):`, to cut mistakes to ~0). [] -- 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/WI3FDR2RUXMXIQZ5E7DJ5DTZT75Z4SUW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
On Sun, Nov 15, 2020 at 03:18:29PM +0300, Paul Sokolovsky wrote:
> > > amount of work to implement pattern matching is certainly an order
> > > of magnitude larger than to introduce constants
[...]
[Steve]
> > Here's a toy proposal,
> []
>
> The baseline of my version is much simpler:
>
> # This makes "const" a kind of hard keyword for this module
> from __future__ import const
>
> FOO: const = 1 # obviously, this is constant
> Foo_Bar: const = 2 # this is too
> foo: const = 3 # and like it or not, but this is constant either
>
> "const" annotation is recognized by compiler (scope resolving
> component, aka symtable builder to be exact) as a property orthogonal to
> localness/globalness. Literally, "symtable" module
> (https://docs.python.org/3/library/symtable.html#symtable.Symbol) will
> grow Symbol.is_const() method.
Oh, well, if all it takes is to add a new keyword, then constants are
easy! No need to worry about how constantness affects name resolution,
or how the syntax interacts with type-hints:
spam: const: Widget = build_widget(*args)
# Maybe this is better?
# let spam: Widget = build_widget(*args)
or how "constant" interacts with mutability:
spam: const = []
spam.append(99) # Allowed?
spam.extend(items)
spam.sort()
or for that matter, whether or not constants are actually constant.
spam: const = 1
spam = 2
If constants aren't actually constant, but just a tag on symbols, then
you would be right, it probably would be trivially easy to add
"constants" to Python.
But I think most people agree making them behave as constants is a
pretty important feature. *The* most critical feature of all, really.
Given a declared constant:
# Module a.py
x: const = None
how do you prevent not just code in module `a` from rebinding the value:
x = 1
globals()['x'] = 2
exec('x = 3', globals())
but other modules as well:
# Module b.py
import a
a.x = 'spam'
vars(a)['x'] = 'spam'
exec('x = 3', vars(a))
--
Steve
___
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/MVDPBRBONUQXJK2RW5VX24YCGD4NX3EM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
On 15/11/20 10:48 pm, Paul Sokolovsky wrote: > [from PEP 635] Pattern matching is complimentary to the object-oriented paradigm. BTW, there seems to be a typo here -- I think it's meant to be "complementary". 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)." That's not certain at all, and moreover it's not just a matter of work, it's a language design issue that would require its own extensive investigation and debate. Members of the intended audience (people very familiar with Python and its technicalities) can be expected to understand this, so the PEP doesn't need to spell it out. 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 We can't just do it "like C does" because C requires variables to be declared and Python doesn't. 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". No, other reasons include that it would require making unrelated language changes that open various other wormcans. nobody del'eted local variables behind users' backs either, before somebody started to do that for exception clause variables. There was a good reason for that having to do with reference cycles. Nobody liked it much, but we didn't really have a choice. There is no such pressing need for special scope rules in match statements. -- Greg ___ 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/MUCUIUF5LSQOBJDZW3OVHH253GIJBVDN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
Matching *should* look like instantiation ... case Point(2, 4) *should* mean "Does it match the object that Point(2, 4) would create?". case Point(2, y=4) is less crucial, because they *could* rewrite the call -- but why should they have to? Changing from constants, and case Point(x=a, y=b) suddenly means x is the already externally bound name and *a* is being assigned to, so it doesn't need to have been defined previously? What advantage can there be in re-using syntax to mean something opposite to what it normally does? Others have objected to both case Point(x as a) and case Point(a:=x) # I dislike it, but it isn't as bad as the raw = but I am missing the problem, other than the confusion binding always brings. To me, they do both seem to say "It matches the object that would be created by Point(x) for *some* x, and an example/witness x that works is now stored in a. If there is no way to resolve this, I would honestly prefer to require nested matching, vs using call signatures in a way opposite to their normal usage. -jJ ___ 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/ETWGXN3QMKFK6E2LNSAVMZATT625QJ74/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
case mylib.STATUS_OK, >result: case mylib.STATUS_OK, >>result: case mylib.STATUS_OK, ->result: The second problem with those is that ">" has a very strong tie to "greater than". I think -> or even >> *might* be enough to overcome that, but I'm not comfortable. (The first problem, of course, is that the PEP authors are still reluctant to require any sigil at all, for what they assume will quickly become the default case.) -jJ ___ 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/KK7ECGM2SMV3ZUV2QGHY65IRTSZS76TH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means exactly the opposite. No problem here, I suppose. So match p: case Point(x=a, y=b): is a way of saying "solve p = Point(x=a, y=b) for a and b". I understand your distaste for this syntax, but I see no problem in principle. It's a problem of programmer habits and the evident inconsistency with forms like "case Point(x=1, y=2)". This is especially true when a or b is already bound. ___ 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/4G5D3DAI7B77LF3GD2YIOQZUBKYFUD7P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] constants in Python: Starting simple and gradually adding more features, was: Re: Pattern Matching controversy
Hello, On Mon, 16 Nov 2020 08:39:30 +1100 Steven D'Aprano wrote: [] > > The baseline of my version is much simpler: > > > > # This makes "const" a kind of hard keyword for this module > > from __future__ import const > > > > FOO: const = 1 # obviously, this is constant > Oh, well, To start with, in the original thread I wanted to concentrate on issues of the PEP634/PEP635, and whether these issues are prominent enough to hope for them being addressed. So, I changed the subject (and we'd soon be excused to python-ideas, indeed, I cc: there). > if all it takes is to add a new keyword, then constants are > easy! A new annotation. And the new subject is "constants in Python: Starting simple and gradually adding more", which hopefully should set the theme. Please remember how we arrived here: it's from the fact that PEP634 doesn't allow for the following trivial code: MY_CONST = 1 match foo: case MY_CONST: We're considering (another alternative) how to address that. Please don't make a leap towards supporting (at once) const-ness equivalent to statically typed languages. > No need to worry about how constantness affects name resolution, > or how the syntax interacts with type-hints: "const" is *the* type hint. > spam: const: Widget = build_widget(*args) That syntax is clearly invalid. And composability of type annotations (aka type hints) is a known, looming issue. We now have https://www.python.org/dev/peps/pep-0593/ , but in all fairness, it seems like a stopgap measure rather than an elegant solution. (In full fairness, entire "typing" module's annotations aren't very elegant, but as we know, it's not a part of language core, but part of CPython's stdlib. That means it's only *one* of possible annotation schemes for *Python*). So, under PEP593, the above would be written spam: Annotated[Widget, const] = build_widget(*args) If you want a glimpse of what alternatives might look, then: given that "|" is going to be used for union types, why not try "&" for composition? spam: Widget & const = build_widget(*args) But again, for "initial support of constants in Python, prompted by the introduction of pattern matching facilities", we don't need to worry about all that right away. > # Maybe this is better? > # let spam: Widget = build_widget(*args) As you remember, at the beginning of my proposal, I wrote "The baseline of my version ...". Baseline == level 0. For "level 2", I considered const spam: Widget = ... I don't think that "let" should be used. We're putting emphasis on *constantness* (not lexical scoping of variables [immutable by functional tradition, though that's "minor"]). JavaScript (now) has both "const" and "let", and I think that's pretty reasonable approach. So, let's save "let" for possible later uses. So, what's "level 1"? As I mentioned, under "level 0", "from __future__ import const" has a magic meaning (akin to other "from __future__"'s). Under "level 1", "const" is just a normal annotation symbol imported from a module. So, following would be possible: = from __future__ import const FOO: const = 1 def fun(): const = 1 # Just a variable in function scope def sub(): # Gimme powerz back from __future__ import const BAR: const = 2 # Back to annotation in global scope BAZ: const = 3 = "level 0" should be implementable in CPython in ~1hr. "level 1" is realistically what we should shoot for. "level 2" (the dedicated keyword), I'm still not sure about. "const" is very baseline annotation, and deserves a dedicated keyword. But the underlying problem is composability of (arbitrary) annotations. I'd rather keep searching for graal in that regard, before giving up and introduce a dedicated thing just for "const". > or how "constant" interacts with mutability: > > spam: const = [] > spam.append(99) # Allowed? > spam.extend(items) > spam.sort() "const" is an annotation just like any other. And it affects *runtime* in the same as any other annotation in CPython affects it: in no way. "const" is however introduced as a hint for *compile-time*, so compiler could make some simple inferences and maybe even optimizations based on it. > or for that matter, whether or not constants are actually constant. > > spam: const = 1 > spam = 2 Compiler can, and thus would, catch that as an error (warning for a beta version?). > If constants aren't actually constant, but just a tag on symbols, > then you would be right, it probably would be trivially easy to add > "constants" to Python. Right. > But I think most people agree making them behave as constants is a > pretty important feature. As mentioned, "const" is just an annotation like any other, except compiler has some insight into it. Dealing with runtime is distant goal for CPython. (Which is for now offloaded to static type checkers and libraries/alternative Python implementations.) > *The* most critical feature of a
