Another thought: a common theme in the PEP is requests for more rationale about design decisions, and more introductory material. I worry that adding everything they're asking for would cause the PEP to fall under its own weight. One idea I have is to split the PEP in three new PEPs:

• Specification -- as precise and formal as possible
• Rationale -- careful explanations of the reason for every design decision
• Tutorial -- an introduction for people with moderate Python experience

Each of these has its own audience: The Specification is for would-be implementers and to answer future questions about what the semantics ought to be in specific cases. The Rationale is for people who want to critique or discuss the PEP, and may occasionally be useful in situations where the Specification sheds insufficient light on the intentions. The tutorial is for people who are just excited about using pattern matching -- and also required reading before anyone can really understand the Specification or the Rationale.

The current Rejected ideas would go in the Rationale. I suppose Deferred ideas could go there too. (Where else could they go? Maybe we don't need to bring them up except where they are important to the Rationale.)

Also see python/peps#1573 -- Carol rewrote the Abstract and Overview for us.

I was worried that the SC might not reach a consensus on this issue - given the traffic on the python-dev lists, if you filter out the random suggestions and bikeshedding, the feedback comments mostly fall into several distinct factions or camps, and the SC feedback seems to follow the same pattern. Ugh.

I suggest we examine the biggest and most contentious issues first - if we can't get closure on those, there's really no point in polishing up the PEP text.

Possibly we could ask the SC to present us with votes on each of the biggest issues? I would include at least the following:

• Do we need to consider lvalue marking?
• Do we need to change the wildcard to ? ?
• Do we need to change | to or ?
• Assuming we do what the SC asks on those three points and clarify the text in minor ways where they've asked, would they accept the PEP?

There's a looming larger issue, which is whether the PEP has enough bang for the buck; my last bullet attempts to quantify that.

Another murky issue is whether the SC considers the PEP to have too many "exceptions". (Then again, our use of _ as a wildcard was marked as an exception.)

Finally, Victor Stinner is himself a wildcard; for personal reasons (not having to do with the PEP, the SC or Python) he has abstained from commenting. But I imagine we'll need his vote.

I had a similar thought to yours - it would be useful to know the impact of a specific decision on the SC consensus. It's not clear from reading the comments how a given edit of the PEP would change the consensus.

So Guido and I chatted on Zoom, and we decided that:

1. We will start a new Github issue for each of the major points brought up by the SC, rather than continuing the discussion in the existing topics.
2. However, each of those issues should contain links to the previous threads.

This means that we don't need to slog through the entire history of the topic - but we can if needed.

I've already created one issue for the loads vs. stores issue.

Being new to the game, I am wondering how to read many of the SC's comments, and consider it quite an important aspect. Concerning the wildcard, for instance, does it mean that we must change the semantics of _ in order to have any chance of acceptance, or does it rather mean that we have not made the case for our design well enough to convince everyone?

Could any proposal rally the necessary 3 votes out of 5? And would the SC itself agree to accept the PEP if it came to 3-2?

If the SC is open to a discussion, I am happy to throw in the necessary work to improve the PEP to a state where it is generally accepted (or at least acceptable). I really appreciate that Carol has taken the time and effort to rewrite/improve parts of the PEP, and I consider it as a sign that we should move forward and tackle the various issues.

I quite like the idea to split it into three PEPs and think that would really help in making it more approachable (I wasn't aware that we might have that option ^_^).

Hi! I'm not gone, just catching up with everything.

Summary of my position:

• I've felt repeatedly that we need some tutorials supporting this, and conflicted that the PEP was too big and that the PEP format doesn't lend too well for it. If the steering council is up for reading that kind of materials and it helps advocate for the PEP, I'm all for writing something like that (I could get started tomorrow)
• Regarding the concrete syntax changes, I'm generally happy to change whatever helps this getting accepted (or in other words: having this PEP with a different concrete syntax is for me generally better than not having it at all)
• On a meta/political side of "selling" PEP622: I am wondering if there are alternate approaches that could help passing this. Off the top of my head: we could push other smaller PEPs with some of these ideas like dict destructuring, outside of pattern matching. If those get accepted, this PEP start looking more "natural" or less "controversial".

[...] having this PEP with a different concrete syntax is for me generally better than not having it at all

I think we probably all agree on this one. The question is, however, what "concrete syntax" in this context means. We just very recently had a discussion about replacing walrus patterns with an as-keyword, which is an example of a concrete syntax that we can easily change without modifying the actual ideas behind pattern matching. And while I frankly cannot understand the reservations against | between alternatives, I could live with using or instead. It's certainly not as elegant, but still not touching the core ideas.

However, the load/store discussion is rather something that touches the very basis of what pattern matching is. And I would not want to just change that without a proper and thorough discussion.

Besides that, I think we should not change or modify something too hastily, but first seek out a discussion, anyway. We have had long discussions and considered a lot of possible variations in the entire design space. I don't think that we should just change everything because others might find it "nicer". I would want to get some well founded argument as to why we should modify our design.

[...] we could push other smaller PEPs with some of these ideas [...]

I am not convinced that this would work. On the one hand, that's an awful lot of work to put in for each of possible piece to convince people and argue about all the bike shedding. That's a route that will most likely take us several years to get to actual pattern matching. On the other hand, I don't think that you can cut up pattern matching in little pieces like this. We did have one or the other discussion about ramifications of one choice or another, demonstrating how much it is all very much interwoven with huge dependencies concerning design choices. This is particularly true if there are proposals to extend a feature that seem quite valid and nice when looking at it isolated, but would cut into the overall design catastrophically.

These are all great comments.

One idea for "selling" the PEP would be to make it easier for people to get their hands on the prototype implementation. I know we had published it in a notebook site, but to be honest I had never heard of that site previously. And for playing around with Python I really don't want to work online in a web page - I want something that runs on my local machine, possibly in a venv.

However, the load/store discussion is rather something that touches the very basis of what pattern matching is. And I would not want to just change that without a proper and thorough discussion.

We agree here, this is somewhat more than concrete syntax. I was mostly talking about things like:or vs |, _ vs ? , and as vs :=

Regarding splitting up the PEP... I was brainstorming possible plan Bs if we find this hard to push. I think a few things can be extracted, but what I'm trying to say is that we should explore other directions that may help this through (splitting was just one possible idea, I'm trying to invite more).

What I count from the feedback in term of "votes" is:

1. we have one "I'd like pattern matching in Python, not this way" (that's a -1 for the PEP, which can be flipped with big changes)
2. we have one "I'd like pattern matching, I have these issues"
3. we have two people sending a blanket list of tweaks and comments on specific issues, but it's no clear to me what's their "big picture" position (I was thinking on just asking them, unless any of you is against that?)
4. and an unrelated abstention

What I'd like to hear about you all in this meta-issue are what are the strategies that you think can lead towards getting more people on board.

Going back to the idea of splitting the PEP in three parts, we would also need to find a place where we can write at length about why we think this is important, useful, etc., and fits in Python. (Using a corny phrase it will make Python better prepared for the next decades.)

I could send an email to the SC proposing to meet with them on Zoom (or maybe Skype -- I don't know what they use now). Scheduling will be hard so I'd say whoever can make it at the time the SC agrees to see me is also welcome. In that email I would also sketch out our position on the three big syntax/semantics issues (lvalues, wildcards, OR), which is roughly that while wildcards and OR are negotiable, lvalues open up too big a can of worms. I'll also ask if they're open to having separate votes on each of these three issues, and what it would mean for the PEP if we could get agreement on all three (which for me would mean we can go with whatever the SC majority votes for on wildcards and OR, but I'm not budging on lvalues).

Yes, I am happy with a meeting on Zoom/Skype, and I welcome the idea of knowing more concerning their positions on specific issues.

We had a 90-minute Skype meeting with a subset of the SC (Brett for 30 minutes, Thomas, Carol and Barry for an extra hour). Quick notes:

• We're not introducing sigils for stores (we may in the future reintroduce the leading dot to load an unqualified name)
• Examples in the PEP should focus on new code, not refactoring
• We'll keep '_' as a wildcard, but Thomas will write a separate PEP proposing '?' as a wildcard for other contexts
• We'll keep '|' for OR-patterns
• We'll keep the current indentation scheme
• We're not adding an 'else' clause (the SC members were also divided on how it should align :-)
• The language on undefined behavior is okay, but we should stop using the phrase "considered buggy"
• We'll split the PEP into three new PEPs (see Organizing the SC feedback #142 (comment))

Things we didn't get to:

• Using 'is' for True, False and None (I think we should do this)
• Switching 'x := p' to 'p as x' (I'm not so sure about this)

I accidentally marked most of the sc-feedback issues as "fully pepped", because they are all described in adequate detail in the spec, PEP 634. However, each of these decisions needs to be carefully explained and motivated in PEP 636, so I changed the labeling to "needs more pep". Sorry about that.