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@python.org>
Subject: [Python-Dev] Pattern matching reborn: PEP 622 is dead, long
        live PEP 634, 635, 636
To: Python-Dev <python-dev@python.org>
Message-ID:
        <CAP7+vJKzn+y8gqAFUr1g=jOCk2if496ST00Ke8Mg921Yp5ZitQ@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?)*