Python-Dev

Download

python-dev@python.org

November 2020

92 participants
52 discussions

Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
by Federico Salerno Nov. 3, 2020

Nov. 3, 2020

Re: symbol for lookup Whatever happened to the proposal of using . as prefix? If memory serves, the main objection was about it being hard to see, but is it really? We use fixed width fonts for a reason, and there are other places a dot is quite critical (has any php programmer ever mistaken a .= for a = ?) without it's size ever causing issues. I think . is visible enough while being aesthetically inoffensive. Am i missing some problem or important past objection to it?

3 2

Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636
by Tin Tvrtković Nov. 2, 2020

Nov. 2, 2020

Hi, first of all, I'm a big fan of the changes being proposed here since in my code I prefer the 'union' style of logic over the OO style. I was curious, though, if there are any plans for the match operator to support async stuff. I'm interested in the problem of waiting on multiple asyncio tasks concurrently, and having a branch of code execute depending on the task. Currently this can be done by using asyncio.wait, looping over the done set and executing an if-else chain there, but this is quite tiresome. Go has a select statement (https://tour.golang.org/concurrency/5) that looks like this: select { case <-ch1: fmt.Println("Received from ch1") case <-ch2: fmt.Println("Received from ch2") } Speaking personally, this is a Go feature I miss a lot when writing asyncio code. The syntax is similar to what's being proposed here. Although it could be a separate thing added later, async match, I guess. > Message: 2 > Date: Thu, 22 Oct 2020 09:48:54 -0700 > From: Guido van Rossum <guido(a)python.org> > Subject: [Python-Dev] Pattern matching reborn: PEP 622 is dead, long > live PEP 634, 635, 636 > To: Python-Dev <python-dev(a)python.org> > Message-ID: > <CAP7+vJKzn+y8gqAFUr1g= > jOCk2if496ST00Ke8Mg921Yp5ZitQ(a)mail.gmail.com> > Content-Type: multipart/alternative; > boundary="00000000000039e83905b2453edf" > > --00000000000039e83905b2453edf > Content-Type: text/plain; charset="UTF-8" > > After the pattern matching discussion died out, we discussed it with the > Steering Council. Our discussion ended fairly positive, but there were a > lot of problems with the text. We decided to abandon the old PEP 622 and > break it up into three parts: > > - PEP 634: Specification > - PEP 635: Motivation and Rationale > - PEP 636: Tutorial > > This turned out to be more work than I had expected (basically we wrote all > new material) but we've finally made it to a point where we can request > feedback and submit the new version to the SC for approval. > > While the text of the proposal is completely different, there aren't that > many substantial changes: > > - We changed walrus patterns ('v := p') to AS patterns ('p as v'). > - We changed the method of comparison for literals None, False, True to use > 'is' instead of '=='. > - SyntaxError if an irrefutable case[1] is followed by another case block. > - SyntaxError if an irrefutable pattern[1] occurs on the left of '|', e.g. > 'x | [x]'. > - We dropped the `@sealed` decorator and everything aimed at static type > checkers. > > [1] An irrefutable pattern is one that never fails, notably a wildcard or a > capture. An irrefutable case has an irrefutable pattern at the top and no > guard. Irrefutability is defined recursively, since an '|' with an > irrefutable pattern on either side is itself irrefutable, and so is an AS > pattern with an irrefutable pattern before 'as'. > > The following issues were specifically discussed with the SC: > > - Concerns about side effects and undefined behavior. There's now some > specific language about this in a few places (giving the compiler freedom > to optimize), and a section "Side Effects and Undefined Behavior". > > - Footgun if `case NAME:` is followed by another case. This is now a > SyntaxError. > > - Adding an 'else' clause. We decided not to add this; motivation in PEP > 635. > > - Alternative 'OR' symbol. Not changed; see PEP 635. > > - Alternative wildcard symbol. Not changed, but Thomas wrote PEP 640 which > proposes '?' as a general assignment target. PEP 635 has some language > against that idea. > > - Alternative indentation schemes. We decided to stick with the original > proposal; see PEP 635. > > - Marking all capture variables with a sigil. We all agreed this was a bad > idea; see PEP 635. > > -- > --Guido van Rossum (python.org/~guido) > *Pronouns: he/him **(why is my pronoun here?)* >

6 11