[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

It would be fantastic if these were expressions rather than statements. Imagine being able to write things like: ```python @memoized def fibonacci(n): match n: case 0: (return/yield?) 0 case 1: 1 case _: fibonacci(n - 2) +

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 30/07/2020 00:34, Nick Coghlan wrote: the proposed name binding syntax inherently conflicts with the existing assignment statement lvalue syntax in two areas: * dotted names (binds an attribute in assignment, looks up a constraint value in a match case) * underscore targets (binds in

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 7 Aug 2020 17:33:04 -0300 "Joao S. O. Bueno" wrote: > > Branch comparison for the match/case version: > https://github.com/jsbueno/terminedia/compare/patma For me, your example is bonkers from the start. Anyone who thinks `Rect(left_or_corner1=None, top_or_corner2=None, right=None,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07Aug2020 2133, Joao S. O. Bueno wrote: Enough cheaptalk - links are here: tests: https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356 Branch comparison for the match/case version: https://github.com/jsbueno/terminedia/compare/patma

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Just taking a ride on the thread here, I made a quick talk on the proposed feature for a local group, and in the process I refactored a "real world" class I have in a project, which features a complicated __init__ due having lots of different, optional, ways to be initialized. I can tell I

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Thu, Aug 6, 2020 at 3:46 AM Mark Shannon wrote: > Hi Barry, > > How long do we have to present objections to PEP 622? > We haven't discussed a timeline among ourselves yet (unless it was discussed at the last meeting which missed ). > > I don't feel that the PEP gives adequate prominence

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hi Barry, How long do we have to present objections to PEP 622? I don't feel that the PEP gives adequate prominence to the objections so far raised, and there are more issues I would like to bring up. Cheers, Mark. On 05/08/2020 5:58 pm, Barry Warsaw wrote: PEP 622 is already on the SC’s

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Javascript hasn't it yet, but there is an active proposal for it in the standardization committee: https://github.com/tc39/proposal-pattern-matching On Wed, 5 Aug 2020 at 21:34, Luciano Ramalho wrote: > On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn wrote: > > And experience from other

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, Aug 5, 2020 at 8:14 PM Larry Hastings wrote: > It's interesting to consider how C# did it. For example, at the same time > they added pattern matching, they also added "discards", which are > (undeclared-only?) variables whose name starts with '_' and whose value is > never retained.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

It's interesting to consider how C# did it.  For example, at the same time they added pattern matching, they also added "discards", which are (undeclared-only?) variables whose name starts with '_' and whose value is never retained.  I'm not sure, but I believe the language previously

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Off the top of my head for recently happened and fairly mainstream language: C# added it in 8.0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 On Wed, Aug 5, 2020 at 3:33 PM Luciano Ramalho wrote: > On Tue, Aug 4, 2020 at 1:37 PM Tobias

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Tue, Aug 4, 2020 at 1:37 PM Tobias Kohn wrote: > And experience from other programming languages who took the leap to having > pattern matching shows that it quickly becomes a quite intuitive and easy to > use feature. The languages I know about that have pattern matching had it from the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

PEP 622 is already on the SC’s agenda for review. -Barry > On Aug 5, 2020, at 09:47, Ethan Furman wrote: > > On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: > >> The debate is still going on as to whether "capture" variables should be >> marked... > I don't think the PEP authors are

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, Aug 5, 2020 at 9:48 AM Ethan Furman wrote: > I don't think the PEP authors are debating it any more. Quite frankly, > I wish they would present to the SC and get accepted so we can get > Pattern Matching added to 3.10. :) > We did, a few weeks ago, and the SC is already reviewing it.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, 5 Aug 2020 09:47:30 -0700 Ethan Furman wrote: > On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: > > > The debate is still going on as to whether "capture" variables should be > > marked... > I don't think the PEP authors are debating it any more. That would be a pity.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote: The debate is still going on as to whether "capture" variables should be marked... I don't think the PEP authors are debating it any more. Quite frankly, I wish they would present to the SC and get accepted so we can get Pattern Matching

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 03/08/2020 17:37, MRAB wrote: [snip] A thought occurred to me. By default, the current rules of the PEP could apply, but why not allow prefixing with "as" for a capture and "is" for a value? Yes, I know, comparison of the values is not by identity, but "is" is a short keyword that

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Welcome to python-dev, Rik!  Of course you can email to this list. On 30/07/2020 14:30, Rik de Kort via Python-Dev wrote: I think adding the Walrus operator is trying to solve a problem that doesn't exist. Compare the example from the PEP:     [snip] case (x, y, z): [snip] To

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hi Larry, You are right that just dismissing intuition is wrong.  I should have been more careful with my wording or explain them better, and I would like to apologise if my response came across as too strong in this regard. The actual problem that I see is that we have different

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Thu, 16 Jul 2020 at 19:09, Richard Damon wrote: > One question that comes to mind, does match NEED a colon at the end of it? If > it didn’t have the colon, it wouldn’t need the indent for the following lines. Or something like match t case ("rect", real, imag): return complex(real,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 2020-08-03 05:21, Guido van Rossum wrote: Your point about wanting a way to use an unqualified name as a value pattern is not unreasonable, and as you may recall we had an elegant solution in version 1 of the PEP: a leading dot. However that was booed away by the critics, and there has been

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Your point about wanting a way to use an unqualified name as a value pattern is not unreasonable, and as you may recall we had an elegant solution in version 1 of the PEP: a leading dot. However that was booed away by the critics, and there has been no consensus (not even close) on what to do

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

> `np` analogue is quite a stretch and far-fetched, really. I don't disagree. But `_` is a valid identifier so it shouldn't be special. The solution is incredibly simple: allow repeated identifiers just like in assignment so there is no need for a special wildcard symbol. > .. I disagree

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

That's a strawman argument. I am done arguing about this. On Fri, Jul 31, 2020 at 7:47 PM Nick Coghlan wrote: > > > On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum, wrote: > >> Trust me, the PEP authors are well aware. If we hadn't been from the >> outset, a hundred different proposals to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum, wrote: > Trust me, the PEP authors are well aware. If we hadn't been from the > outset, a hundred different proposals to "deal" with this would have. And > many of those proposals actually made it into the list of rejected ideas. > Moreover, we

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Trust me, the PEP authors are well aware. If we hadn't been from the outset, a hundred different proposals to "deal" with this would have. And many of those proposals actually made it into the list of rejected ideas. Moreover, we rewrote a huge portion of the PEP from scratch as a result

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri., 31 Jul. 2020, 3:14 am Guido van Rossum, wrote: > On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan wrote: > >> I'm still only intermittently keeping up on python-dev, but my main >> concern with the first iteration remains in this version, which is that it >> doesn't even *mention* that the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 31/07/2020 17:24, Rik de Kort via Python-Dev wrote: 1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context. 2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context. 2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had to explicitly capture every variable. I just want to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter. On 31.07.2020 13:42,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/31/20 12:36 AM, Tobias Kohn wrote: And since pattern matching is really a new feature to be introduced to Python, a feature that can be seen in different lights, there is no 'Python-Programmer intuition' that would apply in this case. It's not fair to say "intuition doesn't apply because

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hi Caleb, I will only answer to the second part, as the wildcard issue has been brought up and discussed time and again, and the `np` analogue is quite a stretch and far-fetched, really. One thing that stood out a bit to me as I feel to have seen it a couple of times is the question of

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/30/20 4:31 PM, Caleb Donovick wrote: However if the capture was explicit and any valid target could be used as a capture variable then I could express this cleanly: |def update_point_3d(p: Point3d, pt): match pt: case (p.x=, p.y=): pass case Point2d(p.x=, p.y=): pass ... | I like this

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Adding this feature would be a giant quality of life improvement for me and I really hope it succeeds. So I have been trying to keep up on the debate in this and related thread. While I do want this feature, I agree with a lot of the issues people are raising. First I agree that _ should not

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 08/07/2020 16:02, Guido van Rossum wrote: Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching. After all the discussion on the issue, I can still not stop thinking that there needs to be a visual distinction between "capture" and "match"

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hi Rob, thank you! :) I think I understand the point, but I still don't agree with it. I find it hard to come up with a concrete use case where you would like to name a parameter without specifying it. Suppose we want case Status(user, n_messages, replies, unicode:=_) Then it might be a little

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan wrote: > I'm still only intermittently keeping up on python-dev, but my main > concern with the first iteration remains in this version, which is that it > doesn't even *mention* that the proposed name binding syntax inherently > conflicts with the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

I'm very new to this mailing list so I'm not sure it's my place to email, but I'd like to weigh in and maybe it will be useful. If not you can always ignore ;) I think adding the Walrus operator is trying to solve a problem that doesn't exist. Compare the example from the PEP: def

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano wrote: > On Sat, Jul 18, 2020 at 09:25:45AM -, > emmanuel.coir...@caissedesdepots.fr wrote: > > > This approach, for me, seems to come from functionnal languages where > > pattern matching is a thing. The proposed "match" clause tends to > >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 17 Jul 2020 at 12:28, Gustavo Carneiro wrote: > > > On Fri, 17 Jul 2020 at 12:26, wrote: > >> Hello everyone, >> (...) >> But... looking at the examples, it wasn't very obvious that some >> variables were catching variables and some others were matching ones. >> I then read in details

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

I'm still only intermittently keeping up on python-dev, but my main concern with the first iteration remains in this version, which is that it doesn't even *mention* that the proposed name binding syntax inherently conflicts with the existing assignment statement lvalue syntax in two areas: *

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 18/07/2020 11:23, emmanuel.coir...@caissedesdepots.fr wrote: Ethan Furman wrote: The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 16/07/2020 18:13, MRAB wrote: On 2020-07-16 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Emily Bowman wrote: > SPAM: Final = "spam" > then it'll throw an error. Likewise, the first time it does something > totally unexpected like insert something into what they thought held a > match pattern, it'll break their initial assumptions and hopefully get them > to read the documentation, to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Steven D'Aprano wrote: [...] > In any case, functional languages like Haskell, F# and ML are not the > only languages with pattern matching. Non-FP languages like C#, Swift, > Rust and Scala have it, and even Java has an extension providing pattern > matching: >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/18/2020 6:23 AM, emmanuel.coir...@caissedesdepots.fr wrote: Ethan Furman wrote: The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sat, Jul 18, 2020 at 3:29 AM wrote: > > adept at ignoring them, we will again have difficulties when debugging > > as we won't easily see them. > > Besides which, the problem is solved: > > > > namespace.var is a lookup > > var is a store > > These rules can't be deduced from a few examples,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sat, Jul 18, 2020 at 09:25:45AM -, emmanuel.coir...@caissedesdepots.fr wrote: > This approach, for me, seems to come from functionnal languages where > pattern matching is a thing. The proposed "match" clause tends to > mimic this approach, and it can be a good thing. But the Python's >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sat, Jul 18, 2020 at 3:46 AM Terry Reedy wrote: > > A major points of Kohn's post is that 'case' is analogous to 'def' and > match lists are analogous to parameter lists. In parameter lists, > untagged simple names ('parameter names') are binding targets. > Therefore, untagged simple names

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Ethan Furman wrote: > The problem with any kind of sigil/keyword is that it becomes line noise > -- we would have to train ourselves to ignore them in order to see the > structure and variables we are actually interested in. Once we become Every syntax element can become noise once we're used

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Terry Reedy wrote: > A major points of Kohn's post is that 'case' is analogous to 'def' and > match lists are analogous to parameter lists. In parameter lists, I'm sorry to disagree, but match lists share very few things in common with today's parameters list, and introduce a full new

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 17 Jul 2020, Ethan Furman wrote: The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we become adept at ignoring them, we will again

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/17/2020 7:23 AM, emmanuel.coir...@caissedesdepots.fr wrote: Hello everyone, I'm sorry if my proposition has already being said, or even withdrawn, but I think that capture variables shouldn't be as implicit as they are now. I've looked at the PEP very quickly, jumping on the examples to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, Jul 17, 2020 at 3:54 PM Guido van Rossum wrote: > > On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov > wrote: >> >> I've built the reference implementation and I'm experimenting with the >> new syntax in the edgedb codebase. It seems to have plenty of places >> where pattern matching adds

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, Jul 17, 2020 at 1:45 PM Yury Selivanov wrote: > I've built the reference implementation and I'm experimenting with the > new syntax in the edgedb codebase. It seems to have plenty of places > where pattern matching adds clarity. I'll see if I find particularly > interesting examples of

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

I've built the reference implementation and I'm experimenting with the new syntax in the edgedb codebase. It seems to have plenty of places where pattern matching adds clarity. I'll see if I find particularly interesting examples of that to share. So far I'm +1 on the proposal, and I like the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/17/20 8:26 AM, Gustavo Carneiro wrote: I kind of agree it is nicer to be more explicit.  But somehow x= looks ugly. It occurred to me (and, again, apologies if already been mentioned), we might use the `as` keyword here. The problem with any kind of sigil/keyword is that it becomes line

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 17 Jul 2020 at 12:26, wrote: > Hello everyone, > > I'm sorry if my proposition has already being said, or even withdrawn, > but I think that capture variables shouldn't be as implicit as they > are now. I didn't see any mention of capture variable patterns in > the rejected ideas. So

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hello everyone, I'm sorry if my proposition has already being said, or even withdrawn, but I think that capture variables shouldn't be as implicit as they are now. I didn't see any mention of capture variable patterns in the rejected ideas. So here is my idea: I've looked at the PEP very

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/16/2020 10:00 AM, Rhodri James wrote: On 16/07/2020 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 2020-07-16 19:05, Richard Damon wrote: On Jul 16, 2020, at 1:36 PM, Chris Angelico wrote: On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno wrote: Tools should adapt to the language, not the other way around. If things had to be done the way they had always been done, without any change,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

> On Jul 16, 2020, at 1:36 PM, Chris Angelico wrote: > > On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno > wrote: >> Tools should adapt to the language, not the other way around. If things had >> to be done the way they had always been done, without any change, for fear >> of people not

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, Jul 17, 2020 at 3:25 AM Federico Salerno wrote: > Tools should adapt to the language, not the other way around. If things had > to be done the way they had always been done, without any change, for fear of > people not being used to it, we wouldn't even have Python at all. People >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 16/07/2020 19:00, Rhodri James wrote: On 16/07/2020 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 2020-07-16 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/else, and nobody seems to think that

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 16/07/2020 17:37, Steve Holden wrote: While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/else, and nobody seems to think that

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

While I understand the point of view that says that match ... : should encapsulate a sequence of indented suites, it seems to me that match/case/case/.../else has a natural affinity with try/except/except/.../finally/else, and nobody seems to think that the excepts should be indented. Or the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/14/2020 09:22 AM, Jim J. Jewett wrote: Larry Hastings wrote: As for leveraging the convention of using '_' for values you don't care about in Python--that's actually why I /don't/ like it as the wildcard pattern.  To date, everyone who uses '_' understands it's just an identifier, no

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Larry Hastings wrote: > As for leveraging the convention of using '_' for values you don't care > about in Python--that's actually why I /don't/ like it as the wildcard > pattern.  To date, everyone who uses '_' understands it's just an > identifier, no different from any other identifier.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/12/20 3:20 PM, Guido van Rossum wrote: On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings > wrote: Having thought about it some, I propose it'd be acceptable to do dead store optimization if-and-only-if optimizations are explicitly enabled, e.g. with

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/2020 19:17, Guido van Rossum wrote: I find it debatable that we should have this at all, since there are other interpretations possible, and honestly I doubt that it’s a common use case. That’s why we’re holding off. Fair enough. All it would do would be save code in a guard

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Mon, Jul 13, 2020 at 10:07 Federico Salerno wrote: > On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote: > > No, that would not be impossible but fraught with problems. This is > discussed in the PEP: > > https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names > > The PEP

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/2020 12:28, Henk-Jaap Wagenaar wrote: No, that would not be impossible but fraught with problems. This is discussed in the PEP: https://www.python.org/dev/peps/pep-0622/#algebraic-matching-of-repeated-names The PEP goes into no detail of what these problems (or "number of

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/2020 15:33, Guido van Rossum wrote: On Mon, Jul 13, 2020 at 04:35 Rhodri James wrote: [Re: forbidding **_ in mapping patterns] I’d rather not. And the argument about disallowing obviously redundant syntax seems weak. My worry about allowing this is that it’ll be cargo culled and

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Mon, Jul 13, 2020 at 04:35 Rhodri James wrote: > On 12/07/2020 23:20, Guido van Rossum wrote: > > So can we please lay this one to rest? > > Sure. One small thing before we leave it; I've decided I don't care > about the special cases of not using _. to lead class names, but > forbidding **_

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/2020 23:20, Guido van Rossum wrote: So can we please lay this one to rest? Sure. One small thing before we leave it; I've decided I don't care about the special cases of not using _. to lead class names, but forbidding **_ in mapping patterns seems unnecessary. I know it's

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Mon, 13 Jul 2020 at 09:30, Federico Salerno wrote: > On 13/07/2020 00:20, Guido van Rossum wrote: > > The need for a wildcard pattern has already been explained -- we really > want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, > _)`. Generating code to assign the value

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/2020 00:20, Guido van Rossum wrote: The need for a wildcard pattern has already been explained -- we really want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, _)`. Generating code to assign the value to `_` seems odd given the clear intent to *ignore* the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Guido van Rossum writes: > [several reasons why not binding _ is a no-op, and] > A note about i18n: [...]. So can we please lay this one to rest? Yes, please! I was just about to ask about that. I could not believe that in July 2020 people were ignoring I18N, especially the fact that I18N

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/20 3:28 pm, Devin Jeanpierre wrote: The compiler changes what local variables exist if there is a read from a variable named 'super', That's fairly harmless if there's a false positive. But accidentally getting all your locals de-optimised would be annoying. -- Greg

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sun, Jul 12, 2020 at 7:36 PM Greg Ewing wrote: > On 13/07/20 7:12 am, Larry Hastings wrote: > > I dimly recall a precedent where the > > presence of locals() in a function body affected code generation, > > The presence of exec used to do that, which is why it was a > statement rather than a

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 13/07/20 7:12 am, Larry Hastings wrote: I dimly recall a precedent where the presence of locals() in a function body affected code generation, The presence of exec used to do that, which is why it was a statement rather than a function. But I don't think locals() ever did -- how would the

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/11/2020 6:31 PM, Guido van Rossum wrote: Hm... Just the fact that people have been arguing both sides so convincingly makes me worry that something bigger is amiss. I think we're either better off without `else` (since the indentation of `case _` cannot be disputed :-), or we have to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 2020-07-12 23:20, Guido van Rossum wrote: [snip] The need for a wildcard pattern has already been explained -- we really want to disallow `Point(x, y, y)` but we really need to allow `Point(z, _, _)`. Generating code to assign the value to `_` seems odd given the clear intent to *ignore*

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings wrote: > Having thought about it some, I propose it'd be acceptable to do dead > store optimization if-and-only-if optimizations are explicitly enabled, > e.g. with "-O". Allowing explicitly-enabled optimizations to observably > affect runtime

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07/11/2020 03:31 PM, Guido van Rossum wrote: On Sat, Jul 11, 2020 at 2:45 PM Ethan Furman wrote: On 07/11/2020 10:29 AM, Jim J. Jewett wrote: To me, "else:" has a slightly different meaning than "case _:"           case _:  essentially a default, ensuring that the match logic is

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Jul 11, 2020, at 13:28, MRAB wrote: > Another possibility is: > >match: >... >case ...: >case ...: It’s ugly, but you could introduce and require a (soft) keyword on the line after match, e.g. match: # Can’t really use `with` here although I think it reads better.

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/11/2020 7:54 PM, Greg Ewing wrote: I can see that being a reasonable choice if you're using 8-space indents, but I don't see that done much in Python. Also, directly translating this into Python leads to something that looks like a mistake:     match x:     case 1:     ...     case

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/12/20 9:04 AM, Daniel Moisset wrote: The existing implementation has optimizations here.  If that's important, we could achieve the same result with a little dataflow analysis to optimize away the dead store.  We could even special-case optimizing away dead stores /only/ to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Rhodri James wrote: > Eric Nieuwland wrote: > >> Just after I hit ‘send’ it dawned on me it might be preferable to make that >> >> match poly: >> p0 = Point(x0, y0) >> p1 = Point(x1, y1) >> p2 = Point(x2, y2) >> case Polygon(p0, p1, p2): >> … >> >> so the part preceded by

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Greg Ewing wrote: > Eric Nieuwland wrote: > >> ... >> match poly: >> p0 = Point(x0, y0) >> p1 = Point(x1, y1) >> p2 = Point(x2, y2) >> case Polygon(p0, p1, p2): >> … >> > > Interesting idea, but what happens if you don't > need any setup? > Do you have to write >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

Hey Larry, just to clarify on a single point you make: On Sun, 12 Jul 2020 at 10:48, Larry Hastings wrote: > [ snip ] > To address 2), bind '_' when it's used as a name in a pattern. > > This adds an extra reference and an extra store. That by itself seems > harmless. > This is not always

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Sun, 12 Jul 2020 at 10:47, Larry Hastings wrote: > In that case, I'd like to make a specific pitch for "don't make '_' special". > (I'm going to spell it '_' as it seems to be easier to read this way; ignore > the quotes.) Overall, this sounds mostly reasonable. I'm cutting nearly

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 11/07/2020 12:20, Paul Sokolovsky wrote: Actually, the whole argument in PEP 622 regarding "else:", that its placement is ambiguous sounds like a rather artificial write-off. Individual "case"'s are aligned together, but suddenly, it's unclear how to align the default case, introduced by

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 11/07/2020 20:13, Eric Nieuwland wrote: Just after I hit ‘send’ it dawned on me it might be preferable to make that match poly: p0 = Point(x0, y0) p1 = Point(x1, y1) p2 = Point(x2, y2) case Polygon(p0, p1, p2):

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/2020 11:38, Larry Hastings wrote: In that case, I'd like to make a specific pitch for "don't make '_' special".  (I'm going to spell it '_' as it seems to be easier to read this way; ignore the quotes.) IIUC '_' is special in two ways: 1) we permit it to be used more than once in a

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/8/20 8:02 AM, Guido van Rossum wrote: Regarding the syntax for wildcards and OR patterns, the PEP explains why `_` and `|` are the best choices here: no other language surveyed uses anything but `_` for wildcards, and the vast majority uses `|` for OR patterns.  A similar argument applies

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

I don't think anyone has asked for more indentation in that sense; it has only even come up in a suggestion of less. (2-space indents for case instead of 4) People do disagree about whether or not case statements (and possibly an else statement) should be indented more than 0 spaces compared

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 12/07/2020 02:04, Guido van Rossum wrote: On Sat, Jul 11, 2020 at 5:58 PM Chris Angelico > wrote: Hang on. Matching happens before assignment, so this should use the previous value of x for the matching. At least, that's my understanding. If you do

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 2020-07-12 01:32, Chris Angelico wrote: On Sun, Jul 12, 2020 at 10:30 AM Greg Ewing wrote: Just had another thought about marking assignment targets. The PEP currently forbids repeating bound names in a pattern to avoid raising expectations that case Point(x, x): would match only

  1   2   >