[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) + fibonacci(

[Python-Dev] Re: PEP 622: Arrow for capture patterns

On 5 Sep 2020 Ram Rachum wrote: > > Hi everyone, > > Sorry if this was proposed already. I looked here > https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern, > search for "idea to make lookup semantics the default". I saw that a few > symbols like $ and ? were pro

[Python-Dev] Re: PEP 622: Arrow for capture patterns

On Sat, Sep 5, 2020 at 8:31 AM Ram Rachum wrote: > case x: > match Point(-> a, -> b): > ... > match -> whatever: > do_something(whatever) > > I like the arrow because it's easy to imagine the value "entering" the > variable. What do you think? I like t

[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 ass

[Python-Dev] Re: PEP 622 questions

On Mon, Aug 17, 2020 at 3:37 AM Mark Shannon wrote: > > > On 16/08/2020 9:41 pm, Guido van Rossum wrote: > > On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra > > wrote: > > Also, I see potential for a caveat: > > > > match number: > >case int: # missing

[Python-Dev] Re: PEP 622 questions

On Mon, Aug 17, 2020 at 10:04 AM Jean Abou Samra wrote: [Jean] > Finally, was as-based syntax considered as an alternative to walrus >> patterns, that is, PATTERN as NAME instead of NAME := PATTERN, as we have >> in the try statement? Given the extensive discussion, I guess it might have >> been

[Python-Dev] Re: PEP 622 questions

> OOI, what possibilities? I'm genuinely interested know what problems PEP 622 > would solve for you. It's somehow the same use case as Oscar Benjamin's: transform algebraic expressions (the goal being to calculate them step by step -- still under development). You have a series of rules to ap

[Python-Dev] Re: PEP 622 questions

Hi, Thanks for your reply! > Le 16 août 2020 à 22:41, Guido van Rossum a écrit : > >> On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra wrote: >> Hi there, >> >> As a poor user, I am extremely excited about the possibilities PEP 622 >> (structural pattern matching) opens. I'd like to ask a fe

[Python-Dev] Re: PEP 622 questions

On 16/08/2020 9:41 pm, Guido van Rossum wrote: On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra > wrote: Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few quest

[Python-Dev] Re: PEP 622 questions

On 16/08/2020 8:23 pm, Jean Abou Samra wrote: Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few questions. OOI, what possibilities? I'm genuinely interested know what problems PEP 622 would solve for

[Python-Dev] Re: PEP 622 questions

On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra wrote: > Hi there, > > As a poor user, I am extremely excited about the possibilities PEP 622 > (structural pattern matching) opens. I'd like to ask a few questions. > > I hope these were not already answered in other threads, which it is hard > to

[Python-Dev] Re: PEP 622 and variadic positional-only args

Oscar Benjamin's study of sympy is part of what prompted this, and does provide a concrete example of why constructors should be echoed. I think in general, the matching has fallen into two categories: (1) Simple literal-like matching, that mostly works OK. There is still some concern over wh

[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 I

[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 liked

[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 t

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

On Thu, Aug 6, 2020 at 04:31 Mark Shannon wrote: > Hi, > > I have two questions about PEP 622, as it stands. > > 1. Is the current version the final version? That is up to the Steering Council. > 2. Is the difference in semantics between the Django example and the > proposed replacement delib

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

Hi Daniel, On 06/08/2020 1:11 pm, Daniel Moisset wrote: Hi Mark, As the specific author of that example (and the author of the big it had on a previous version) let me clarify: The change in semantics is intentional. I could be more explicit, and preserve semantics, but I actually find very

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

Hi Mark, As the specific author of that example (and the author of the big it had on a previous version) let me clarify: The change in semantics is intentional. I could be more explicit, and preserve semantics, but I actually find very likely that the original code does not support other sequence

[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 a

[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 programming

[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 permitt

[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 star

[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 deba

[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. T

[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. Readabilit

[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 ad

[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 alrea

[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 the

[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 cultu

[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, imag

[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 inste

[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 "deal

[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 rew

[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 (everythin

[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 writ

[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, L

[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 intuiti

[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 p

[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 be

[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" va

[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 us

[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 exi

[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 make_point_3d

[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 > > mimic

[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 so

[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: * dott

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

I think we are storing up trouble unless we     1) Allow arbitrary expressions after `case`, interpreted *as now*     2) Use *different* syntaxes, not legal in expressions, for             alternative matching values (i.e. not `|` or `or`) (NB simply stacking with multiple `case` lines is one pos

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Hi Rob, You are right: the grammar should probably read `suite` rather than `block` (i.e. the `pass` is necessary).  Thanks for catching this! As for the second question, I assume there might be a slight oversight on your part.  The last line in the example replaces the string `"_"` rather th

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note that the following issues are already open and will be responded to separately; please don't bother commenting on

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Without arguing for or against allowing a capture variable, IMO rather than syntax like     match into : it would be far better (and not require a new keyword) to write this as     with as match : Rob Cliffe On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If you've commented and you'r

[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 be

[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 try/except/except/.../finally/e

[Python-Dev] Re: PEP 622 constant value syntax idea

On 16/07/2020 08:16, Baptiste Carvello wrote: Hello, Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit : Hi, I had an idea regarding the pattern matching issue of comparing with a previous constant variable instead of assigning to a new local variable. I'm not sure if this has b

[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: > http://tom.loria.fr/wiki/index.ph

[Python-Dev] Re: PEP 622 aspects

On Sun, Jul 19, 2020 at 3:00 PM Tobias Kohn wrote: > Quoting Koos Zevenhoven : > > > (1) Class pattern that does isinstance and nothing else. > > > > If I understand the proposed semantics correctly, `Class()` is > equivalent to checking `isinstance(obj, Class)`, also when `__match_args__` > is n

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 08/07/2020 16:15, MRAB wrote: On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote: Why not use '=' to distinguish binding from equality testing:       case Point(x, =y): # matches a Point() with 2nd parameter equal to y; if it does, binds to x. This would allow a future (or present!) exte

[Python-Dev] Re: PEP 622 aspects

Hi Koos, Let me try and address some of the concerns and questions you are rising.  I am replying here to two emails of yours so as to keep traffic down. Quoting Koos Zevenhoven : > (1) Class pattern that does isinstance and nothing else. If I understand the proposed semantics correc

[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 bec

[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, o

[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 idea: "match case object" to represent match patterns

On 18/07/2020 11:09, Steven D'Aprano wrote: On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote: We don't, after all, confuse function calls for references to a function, or vice-versa. Beginners do. Frequently. Sometimes it is quite a hurdle for them to learn to write `function()

[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 in

[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 concept

[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns

On Sat, Jul 18, 2020 at 10:58:17AM +0200, Federico Salerno wrote: > We don't, after all, > confuse function calls for references to a function, or vice-versa. Beginners do. Frequently. Sometimes it is quite a hurdle for them to learn to write `function()` instead of `function`. And even experi

[Python-Dev] Re: PEP 622 idea: "match case object" to represent match patterns

On 18/07/2020 02:10, Guido van Rossum wrote: [...] it was quickly pointed out by my co-authors that this doesn't fly, because when the parser sees `case other_3d_point:` it doesn't know whether you meant this as a capture pattern (binding the variable `other_3d_point`) or as a pattern object.

[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 idea: "match case object" to represent match patterns

On Thu, Jul 16, 2020 at 9:21 AM Federico Salerno wrote: > [...] Now consider the following refactor: > > 3d_point = MatchCase("Point(x, y, z)") > other_3d_point = MatchCase("Point(_, _, _)") > point_with_my_y = MatchCase("Point(_, {})", my_y) # syntax with {} is > debatable. > other_2d_point =

[Python-Dev] Re: PEP 622: capturing into an explicit namespace

On 18/07/20 4:34 am, Richard Levasseur wrote: match get_point() into m:   case Point(m.x, m.y):     print(m.x, m.y)   ...etc... Personally, I thought this was a rather elegant solution to the load-vs-store problem for names. This is because, essentially, it changes the mental model from "so

[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 th

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

Mark Shannon wrote: > In future, could you avoid editing emails when replying to them? > A lot of context can get lost. I'll add another voice to Ethan's saying that I appreciate having as much as possible trimmed. As long as people are arguing in good faith (and I assume that they are here),

[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 seco

[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 here

[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 quickly,

[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 try/except/except/.../fin

[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 and variadic positional-only args

On Thu, 16 Jul 2020 at 02:09, Guido van Rossum wrote: > > On Wed, Jul 15, 2020 at 4:41 PM Oscar Benjamin > wrote: >> >> I've taken a look through PEP 622 and I've been thinking about how it >> could be used with sympy. >> >> In principle case/match and destructuring should be useful for sympy >>

[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 bei

[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 > lear

[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 try/except/except/.../final

[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 th

[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 finall

[Python-Dev] Re: PEP 622 constant value syntax idea

> From: Baptiste Carvello > Subject: [Python-Dev] Re: PEP 622 constant value syntax idea > > What about simply "is", which is already a keyword? > > AFAIK "is" has no meaning as a prefix operator as of now, so hopefully > it would not make the grammar a

[Python-Dev] Re: PEP 622 constant value syntax idea

Hello, Le 15/07/2020 à 13:37, Mohammad Foroughi via Python-Dev a écrit : > Hi, I had an idea regarding the pattern matching issue of comparing with > a previous constant variable instead of assigning to a new local > variable. I'm not sure if this has been brought up before but instead of > using

[Python-Dev] Re: PEP 622 constant value syntax idea

Hi Mohammad, In addition to what Rhodri James has already well pointed out, here are two additional thoughts on this. At the moment, the keyword `global` is a marker to say that the respective variable is /modified/ by a function.  Your suggestion would invert that meaning and might ther

[Python-Dev] Re: PEP 622 and variadic positional-only args

Hi Oscar On Wed, Jul 15, 2020 at 4:41 PM Oscar Benjamin wrote: I've taken a look through PEP 622 and I've been thinking about how it could be used with sympy. Thank you very much for taking the time to carefully elaborate an interesting possible use case.  I find this very helpful and a

[Python-Dev] Re: PEP 622 and variadic positional-only args

On Wed, Jul 15, 2020 at 4:41 PM Oscar Benjamin wrote: > I've taken a look through PEP 622 and I've been thinking about how it > could be used with sympy. > > In principle case/match and destructuring should be useful for sympy > because sympy has a class Basic which defines a common structure for

  1   2   3   4   5   >