[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

[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

[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

[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

[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

[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

[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!)

[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

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

On 07/14/2020 11:05 AM, Mark Shannon wrote: On 14/07/2020 5:25 pm, Tobias Kohn wrote: On 07/14/2020, Mark Shannon wrote: In future, could you avoid editing emails when replying to them? A lot of context can get lost. I appreciate posters who take the time to trim the parts of an email that

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

Hi Tobias, In future, could you avoid editing emails when replying to them? A lot of context can get lost. On 14/07/2020 5:25 pm, Tobias Kohn wrote: Hi Mark, Thank you for your message.  I might be able to answer some of the questions and also address some issues with the underlying

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

Hi Mark, Thank you for your message.  I might be able to answer some of the questions and also address some issues with the underlying assumptions in your email---after all, we would most certainly want to avoid discussing and reasoning about straw men, as you yourself have repeatedly

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

Hi, As I wrote in an earlier email: For a PEP to succeed it needs to show two things. 1. Exactly what problem is being solved, or need is to be fulfilled, and that is a sufficiently large problem, or need, to merit the proposed change. 2. That the proposed change is the best known solution

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

On 9/07/20 3:26 am, Brandt Bucher wrote: match : case | : ... case | if : ... case | : ... ``` It's safe to use the same decision tree for through , but it must be rebuilt for and , since could have done literally *anything*. I think you're being overly cautious here.

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

Inada Naoki wrote: > Since this is very new system, can we have some restriction to allow > aggressive optimization than regular Python code? The authors were just discussing a related question yesterday (more specifically, can the compiler fold `C() | C()` -> `C( | )`). The answer we arrived

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

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!) extension to other relative operators:

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

On 7/7/20 10:08 PM, 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!) extension to other relative >

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

On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki wrote: > > On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote: > > > > > > These two I would be less averse to, but the trouble is that they make > > the semantics a bit harder to explain. "Dotted names are looked up if > > not already looked up,

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

On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote: > > > These two I would be less averse to, but the trouble is that they make > the semantics a bit harder to explain. "Dotted names are looked up if > not already looked up, otherwise they use the same object from the > previous lookup". If you

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

On 08/07/2020 11:05, Federico Salerno wrote: What I don't like is the use of _ as catch-all, which is different and not interdependent with its use as throwaway. Any name used as a pattern is a catch-all. The only difference between "case dummy:" and "case _:" is that "_" doesn't bind to the

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

On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote: I used to be in this "camp", however, a (I think valid) point was raised that "else:" is not a (full) alternative. Due to the restriction on repeated names (e.g. Point(x, x) is illegal), if you want to "throw away" intermediate matches, you will

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

On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki wrote: > > Since this is very new system, can we have some restriction > to allow aggressive optimization than regular Python code? > > # Class Pattern > > Example: > > match val: > case Point(0, y): ... > case Point(x, 0): ... >

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

Since this is very new system, can we have some restriction to allow aggressive optimization than regular Python code? # Class Pattern Example: match val: case Point(0, y): ... case Point(x, 0): ... case Point(x, y): ... * Can VM lookup "Point" only once per

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

On Sun, Jun 28, 2020 at 8:44 AM Jim J. Jewett wrote: > I actually like that it looks like instantiation; it seems to be saying > "Do we have the sort of object we would get from this instantiation?" > > Unfortunately, this does aggravate the confusion over whether a variable > is being used as a

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

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!) extension to other relative operators:     case Point(x, >y): (although the syntax doesn't

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

Please move this subtopic to a subject that doesn’t have “PEP 622” in its topic. On Tue, Jul 7, 2020 at 17:54 Greg Ewing wrote: > On 8/07/20 5:30 am, Paul Sokolovsky wrote: > > from __future__ import const > > > > FOO: const = 1 > > > > match val: > > case FOO: # obviously matches by

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On 8/07/20 5:30 am, Paul Sokolovsky wrote: from __future__ import const FOO: const = 1 match val: case FOO: # obviously matches by constant's value This would make it *more* difficult to distinguish constants from assignment targets when looking at the match statement, unless you

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On 8/07/20 2:31 am, Henk-Jaap Wagenaar wrote: Would it be possible here to use a syntax/symbol that is illegal instead of _? I think this has been mooted but my favourite (so far) would be "?" so you have "case ?:" and "Point(?, ?)". Would ?name then work instead of ".name" as well? It

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 18:35, Guido van Rossum wrote: > > On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote: >> >> Hopefully the PEP authors intend to post an updated version >> (preferably with a summary of changes, for people struggling to keep >> up with the traffic here!) sometime soon. > > >

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote: > Hopefully the PEP authors intend to post an updated version > (preferably with a summary of changes, for people struggling to keep > up with the traffic here!) sometime soon. > Please consider that the PEP authors also are struggling with the

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

Hello, On Tue, 7 Jul 2020 17:22:28 +0100 Henk-Jaap Wagenaar wrote: [] > > >> I don't like the .name syntax (grit on Tim's monitor; does [] > "PEP 622: Ditch leading dots for name loads": this is now an > ex-syntax, it is bereft of life (for this, draft, of the PEP, might > come back

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I don't like the .name syntax (grit on Tim's monitor; does not >> suggest the meaning). [...] But I don't know what syntax (where >> necessary) to suggest. > > https://photos.app.goo.gl/xN68s3QMMBTPTLD47

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 17:09, Paul Moore wrote: > On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar > wrote: > > > > On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < > python-dev@python.org> wrote: > >> > >> I don't like the .name syntax (grit on Tim's monitor; does not > >> suggest

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, Jul 7, 2020 at 8:37 AM Rhodri James wrote: > I'm not quite convinced about making "_" non-binding, mostly because of > the knock-on effects in the PEP for other types of patterns. It seems > to breed more special cases, and I can't help but feel that's a bad sign. > After spending some

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar wrote: > > On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev > wrote: >> >> I don't like the .name syntax (grit on Tim's monitor; does not >> suggest the meaning). [...] But I don't know what syntax (where necessary) >> to suggest. > >

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On 07/07/2020 15:31, Henk-Jaap Wagenaar wrote: On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: I'm not keen on special treatment of the '_' variable, and would prefer to be able to use 'else:' after 'match'. I used to be in this "camp", however, a

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I don't like the .name syntax (grit on Tim's monitor; does not > suggest the meaning). [...] But I don't know what syntax (where necessary) > to suggest. +1(000) > I'm not keen on special

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

Caveats: - Any expression (unless you allow reference to variables previously bound by the match statement) can just be aliased (as long as you don’t need short circuiting), so it’s not a critical feature. Constant value patterns are the most easily replaceable by if/elif part of PEP 622. - I’m

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

On Sun, Jul 5, 2020 at 12:03 PM Shantanu Jain wrote: > - Finally, I did mention increasing the scope of constant value patterns to > accommodate expressions (as opposed to just dotted names). If we were to do > this, it’s a reason to prefer some syntaxes for constant value patterns over >

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

Apologies if I misunderstand anything, but my suggestion was just an alternative to the dot syntax for constant value patterns (which along with literal patterns are how PEP 622’s proposes to to cover the “more flexible switch” use case). This syntax is more verbose than PEP 622’s dot syntax for

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

I don't see how this extrapolates to arbitrary, extended match expressions? You're proposing a slightly more flexible switch, which match is only intended to be as the most basic case. Even if you purely swapped it out with any the various proposals for identifying a constant vs a target, it's

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

Thank you for this PEP! Pattern matching is really exciting. As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed. Use percent placeholder to indicate lookup

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

Thank you for this PEP! Pattern matching is really exciting. As the PEP mentions and the thread evidences, the current dot syntax for the “constant value pattern” is a tricky point. Given this, I thought I’d throw another suggestion into the bikeshed. Use percent placeholder to indicate lookup

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

Hi, thank you for the comments On Tue, 30 Jun 2020 at 07:18, Greg Ewing wrote: > On 29/06/20 8:47 am, Daniel Moisset wrote: > > < > https://github.com/dmoisset/notebook/blob/811bf66/python/pep622/understanding-pep-622.md> > . > > > You seem to be trying to shoehorn all Python data structures

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

On 29/06/20 8:47 am, Daniel Moisset wrote:  . You seem to be trying to shoehorn all Python data structures into looking like alebraic types, for the sole purpose of being able to claim that PEP 622 is

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

Rhodri James writes: > That's the clearest explanation of why "_" needs to be treated > carefully, but I don't think it argues for the PEP's special treatment. That depends on whether you care about taking advantage of the convention that "_" is a dummy. In fact, _ = gettext partakes of

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

On 27/06/2020 10:36, Stephen J. Turnbull wrote: Richard Damon writes: > As long as the bindings in match also make the symbol a local > (which seems reasonable) then you would get a similar restriction. It's quite different. First, it surely won't make other symbols match-local. Of course

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

On 28/06/2020 21:47, Daniel Moisset wrote: I've been going over the PEP this weekend, trying to get a deeper understanding of what are its main ideas and consequences, and wrote some notes. I'm not posting the notes directly to this list because it's a bit of a long read, but I also tried to

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

Daniel. writes: > IMHO, the most obvious solution is that the bind should be available only > inside case block and if you need to change a global or a nonlocal you do > this explicitly inside the case block, Do you mean case x: x = x ? > if this is the case you can pickup a

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

Richard Damon writes: > I wasn't imply local to the match statement, but if the match is used > inside a function, where using the binding operatior = will create a > local name, even if there is a corresponding global name that matches > (unless you use the global statement), will a match

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

I've been going over the PEP this weekend, trying to get a deeper understanding of what are its main ideas and consequences, and wrote some notes. I'm not posting the notes directly to this list because it's a bit of a long read, but I also tried to make it helpful as an analysis for people

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

I wrote: > > Guido van Rossum wrote: > >> Eric Nieuwland wrote: >> >>> I have some doubt about the keyword: ‘match' seems to be at odds with >>> 'for', 'while', 'with', 'if' as it is more of an action. >>> It's more like 'try' but that statement has a completely different >>> structure. >> >>

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

I actually like that it looks like instantiation; it seems to be saying "Do we have the sort of object we would get from this instantiation?" Unfortunately, this does aggravate the confusion over whether a variable is being used as a filter, vs binding to something from the matched object.

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

What about `case for Point(x, 0):`? It reads very naturally, the presence of "for" hints against Point() being a call to the class, and "for" is an existing keyword that would make no other sense in that position. Examples with other formats such as `case for [x, 0]:` seem to work just as well.

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

On Thu., 25 Jun. 2020, 5:41 am 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

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

Em sáb., 27 de jun. de 2020 às 11:12, Richard Damon < rich...@damon-family.org> escreveu: > On 6/27/20 5:36 AM, Stephen J. Turnbull wrote: > > Richard Damon writes: > > > > > I thought _ was also commonly used as: > > > > > > first, -, last = (1, 2, 3) > > > > > > as a generic don't care

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

On 6/27/20 5:36 AM, Stephen J. Turnbull wrote: > Richard Damon writes: > > > I thought _ was also commonly used as: > > > > first, -, last = (1, 2, 3) > > > > as a generic don't care about assignment. > > It is. But there are other options (eg, 'ignored') if '_' is used for > translation

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

Richard Damon writes: > I thought _ was also commonly used as: > > first, -, last = (1, 2, 3) > > as a generic don't care about assignment. It is. But there are other options (eg, 'ignored') if '_' is used for translation in the same scope. > I guess since the above will create a

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

On Fri, Jun 26, 2020 at 6:42 AM Mark Shannon wrote: > > > Let us start from some anecdotal evidence: isinstance() is one of the > most called functions in large scale Python code-bases (by static call > count). In particular, when analyzing some multi-million line production > code base, it was

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

On 2020-06-26 16:54, Stéfane Fermigier wrote: [...] Here's one example: https://github.com/clojure/core.match (in particular: https://github.com/clojure/core.match/wiki/Understanding-the-algorithm ). Alson some insights from

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

On Fri, Jun 26, 2020 at 3:38 PM Mark Shannon wrote: > > What does "static and dynamic specifications" mean? Surely, there are > just specifications. > There are specifications for both the runtime and the static aspects of the Python programming language. > Python does not have a static

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

On Fri, 26 Jun 2020 at 09:07, Greg Ewing wrote: > On 26/06/20 2:10 pm, Gregory P. Smith wrote: > > match get_shape() as shape: > >case start, end := Line@(shape): > > This looks just as inscrutable to me in its own way. > Absolutely, but that's kind of the point I think: no possible way to

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

Yes, my brain went through the same path. Another minor nitpick: It would be kinda nice if the various types of pattern were listed in the grammar in the same order as the corresponding paragraphs subsequently appear. On 26/06/2020 11:53, Daniel Moisset wrote: Just a minor editorial thing on

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

Hi, For a PEP to succeed it needs to show two things. 1. Exactly what problem is being solved, or need is to be fulfilled, and that is a sufficiently large problem, or need, to merit the proposed change. 2. That the proposed change is the best known solution for the problem being addressed.

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

On 23/06/2020 20:35, Chris Angelico wrote: On Wed, Jun 24, 2020 at 5:30 AM Rob Cliffe via Python-Dev wrote: The PEP is great, but this strikes me as horribly confusing, given that 401|403|404 is already legal syntax. IIUC any legal expression can come between `case` and `:`, but expressions

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

This one is new but I think unrelated and unmentioned: Why is the mapping match semantics non-strict about keys? Besides the "asymmetry" with sequence matches, I think a strict match should be useful sometimes (quickly deconstructing JSON data comes to my mind, where I want to know that I didn't

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

On 25/06/2020 23:20, Emily Bowman wrote: On my personal "potentially inscrutable uses of a tool" this still rates well below list comprehensions, so there's that; the biggest pet peeve I Clearly YMMV. To me list comprehensions like "[f(x) for x in l]" were obviously related to the "f(x) ∀ x

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

On Fri, Jun 26, 2020 at 3:47 AM Paul Moore wrote: > For me, this prompts the question (which I appreciate is more about > implementation than design) - would there be any (significant) > performance difference between [...] > In C, the switch statement was explicitly intended to be faster by >

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

Just a minor editorial thing on the PEP text: The section https://www.python.org/dev/peps/pep-0622/#case-clauses presents a simplified syntax. That one mentions "group_pattern", but the document never mentions (in prose) what a group pattern is. It confused me until I found the definition in the

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

On Fri, 26 Jun 2020 at 11:29, Daniel Moisset wrote: > > I think roughly half of the uses will actually be for "the switch statement > we never had", where all branches would be constants. I've been writing a lot > of code like that these last couple of weeks, so I may be biased (although > the

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

[apologies for the duplicate to Guido, used reply instead of reply to all] To summarize my previous unanswered post, I posted a +1 to the "defaulting to binding vs interpreting NAME as a constant" is a dangerous default. And I submitted a couple of alternate syntactic ways to denote "capture is

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

On Fri, 26 Jun 2020 at 03:37, Gregory P. Smith wrote: > > Litmus test: Give someone who does not know Python this code example from the > PEP and ask them what it does and why it does what it does: > > match get_shape(): > case Line(start := Point(x, y), end) if start == end: >

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

On Fri, Jun 26, 2020 at 12:42 AM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > 1) In the beginning of the "Mapping Pattern" section: > "{" (pattern ":" pattern)+ "}" > This is spelt inconsistently: there is a `+` before the closing `}` > but not after the opening

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

Some proof-reading of the PEP.  I apologise if this is out of date. 1) In the beginning of the "Mapping Pattern" section:         "{" (pattern ":" pattern)+ "}"     This is spelt inconsistently: there is a `+` before the closing `}` but not after the opening `{`. 2) The second code

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

On 26/06/20 6:21 am, Pablo Galindo Salgado wrote: Which means that users can do a positional match against the proxy with a name pattern: match input:     case datetime.date(dt):         print(f"The date {dt.isoformat()}" I think that would be an incorrect way for matching on datetime to

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

On 26/06/20 5:45 pm, Ned Deily wrote: Hasn't "|" been used in a similar way for decades in Unix/POSIX shell patterns, including with the shell case statement? Yes, but I regard Unix shell syntaxes as just plain weird and not a good model for designing a language on. -- Greg

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

On 26/06/20 2:10 pm, Gregory P. Smith wrote: match get_shape() as shape:   case start, end := Line@(shape): This looks just as inscrutable to me in its own way. -- Greg ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an

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

On 26/06/20 1:08 pm, Paul Svensson wrote: We already allow (x, x) = (1, 2) So, why do we need to disallow binding several values to the same name ? I think it was done because people might expect that to match only if the *same* value appears in both places. Some other languages have pattern

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

On 26/06/20 12:31 pm, Brandt Bucher wrote: I'd imagine that we either find some straightforward way of > opting-in to the current default behavior Maybe special-case 'self' in __match_args__ to mean the object being matched? -- Greg ___ Python-Dev

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

On Jun 25, 2020, at 21:33, Gregory P. Smith wrote: > I prefer "or" to "|" as a combining token as there is nothing bitwise going > on here. "or" reads better. Which is why Python used it for logic > operations in the first place. It is simple English. "|" does not read like > or to anyone

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

Whoops, meant to reply to Gregory on that one, sorry Richard. On Thu, Jun 25, 2020 at 7:15 PM Gregory P. Smith wrote: > > Can I use an i18n'd _("string") within a case without jumping through > hoops to assign it to a name before the match:? > The PEP currently says: > > "The named class

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

On Thu, Jun 25, 2020 at 8:31 PM Richard Damon wrote: > > I thought _ was also commonly used as: > > first, -, last = (1, 2, 3) > > as a generic don't care about assignment. I guess since the above will > create a local, so not overwrite a 'global' function _ for translations, > so the above

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

On 6/25/20 6:48 PM, Emily Bowman wrote: > On Thu, Jun 25, 2020 at 3:41 PM Richard Damon > mailto:rich...@damon-family.org>> wrote: > > Actually, you could make _ less special by still binding the value to > > it, just make it special in that you allow several values to be bound, > and

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

Litmus test: Give someone who does not know Python this code example from the PEP and ask them what it does and why it does what it does: match get_shape(): case Line(start := Point(x, y), end) if start == end: print(f"Zero length line at {x}, {y}") I expect confusion to be the

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

On Wed, Jun 24, 2020 at 7:58 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Ethan Furman writes: > > > _ does not bind to anything, but of what practical importance is that? > > *sigh* English speakers ... mutter ... mutter ... *long sigh* > > It's absolutely essential to

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

On Wed, Jun 24, 2020 at 7:34 PM Taine Zhao wrote: > > e.g., "or", and then I wonder "what does short-circuiting have to do > > with it?". All reuse of symbols carries baggage. > > "or" brings an intuition of the execution order of pattern matching, just > like how people already know about

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

On Thu, 25 Jun 2020, Richard Damon wrote: On 6/25/20 10:42 AM, Greg Ewing wrote: On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it

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

On 26/06/20 5:07 am, MRAB wrote: How do you indicate that you want it to match anything and don't care about the value? case Spam(-> _): Or if that's considered too verbose and we're willing to make _ even more special, it could be just case Spam(_): In that case we would be regarding

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

Ethan Furman wrote: > Ouch. That seems like a pretty serious drawback. Will this issue be > resolved? It's currently being revisited. Realistically, I'd imagine that we either find some straightforward way of opting-in to the current default behavior (allowing one arg to be positionally

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

In this example code from the PEP: match shape: case Point(x, y): ... case Rectangle(x0, y0, x1, y1, painted=True): What is the "painted=True" portion doing? Is it requiring that the painted attribute of the shape object be True in order to match? -- ~Ethan~

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

On 06/25/2020 04:07 PM, Brandt Bucher wrote: Pablo Galindo Salgado wrote: ...users can do a positional match against the proxy with a name pattern: match input: case datetime.date(dt): print(f"The date {dt.isoformat()}" ...if 'datetime.date' were updated to implement a

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

Pablo Galindo Salgado wrote: > ...users can do a positional match against the proxy with a name pattern: > > match input: > case datetime.date(dt): > print(f"The date {dt.isoformat()}" > > ...if 'datetime.date' were updated to implement a non-default __match_args__, > allowing

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

On Thu, Jun 25, 2020 at 3:41 PM Richard Damon wrote: > Actually, you could make _ less special by still binding the value to > it, just make it special in that you allow several values to be bound, > and maybe just define that the result will be just one of the values, > maybe even specify which

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

On Wed, Jun 24, 2020 at 12:46 PM 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

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

On 6/25/20 10:42 AM, Greg Ewing wrote: > On 26/06/20 1:18 am, Rhodri James wrote: >> I will quickly and regularly forget that in this one place, "_" is >> special. > > You don't have to remember that it's special to understand what > 'case _' does. Even if it were treated as an ordinary name, it >

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

On Thu, Jun 25, 2020 at 9:21 AM Rhodri James wrote: > Well, now is the time for expressing surprise :-p > > As I've said before, one of my main problems with the PEP is as you go > through it, more and more special cases and surprises appear, and the > consequences of earlier surprises generate

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

On Thu, Jun 25, 2020 at 3:17 AM Greg Ewing wrote: > On 25/06/20 7:50 pm, Anders Munch wrote: > > Pascal is a precedent for this placement of 'case', > > Yes, but it doesn't use it with "match". In fact it doesn't have > any keyword in front of the values to be matched; it goes like > > case

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

On 06/25/2020 03:00 AM, Greg Ewing wrote: On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like    case n of   1:

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

I was talking with a colleague today about the PEP and he raised a couple of question regarding the match protocol and the proxy result. One question is that taking into account that 'case object(x)' is valid for every object, but it does (could do) something different for objects that have a

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

On Wed, Jun 24, 2020 at 1:38 PM Luciano Ramalho wrote: > Thank you Guido, Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin > for this fun and very useful new feature. > > I do enjoy pattern matching a lot in Elixir—my favorite language these > days, after Python. > > I don't want to start a

  1   2   3   >