PEP 634 and PEP 642

Unfortunately I had completely ignored PEP634 until now (thinking it was something about regular expressions or something), and now finally I see that it is something that it is a subject I would really love. I’m trying to find the discussion on this, because otherwise I’ll probably just rehash things that have been said already, but I can’t find it:-(

So I’ll just ask here, and if no-one answers I’ll just shut up (and won’t be offended:-)

First: I love PEP634 and the functionality it provides, and how it provides it.

But: there is one eyesore that bothers me and that is that when you’re reading a case you have to make a distinction between capture_pattern and all the other patterns. The syntax for capture_pattern also needs an explicit !"_" in its definition because otherwise the parser would also fall foul of that eyesore.

all the other places in python where you have to use a NAME generally don’t accept any other form of “expression-lookalike” constructs, so these don’t cause this confusion while reading.

PEP642 provides a solution to this with an explicit as keyword in the capture_pattern, but it solves a whole lot of other things as well.

Has there been any discussion on requiring the as keyword in a capture_pattern? And why was it rejected?

1 Like

Most of the discussions happened on the Python Ideas and Dev mailing lists:

Actually finding the threads is left as an exercise for the reader. :wink:

Here are some of the discussion threads I found. Unfortunately I can only post 2 links at a time, so I will have to post them as paths to be appended to

  • Thoughts on PEP 634 (Structural Pattern Matching)
  • Concerns about PEP 634
  • Pep 653: Precise Semantics for Pattern Matching
  • SC 2020 recommendation for PEP 634
  • Extrapolating PEP 634: The walrus was waiting for patmat all along
  • PEP 634-636: Mapping patterns and extra keys

For example, the full URL for “Thoughts on PEP 634” would be