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 pointed out.


> Why the use of "shape" in "scare quotes"?

Because the `shape' of an object is not something that is a well-defined term, but rather addresses the intuitive understanding to explain what we are talking about.  It is usually the intention of the abstract to give a rough overview, before delving into the details and more formal descriptions.


> Using a contrived example like this seems like a straw man.  It feels like it is constructed to favour the PEP, whilst being unlike any real code.

It is a trait of many (good) tutorials to present a new structure with an example that highlights its feature in an approachable way rather than coming up with `real code'---particularly given that real code is always surrounded by a larger context, which rather clouds any understanding.  And it would only be a straw man had we constructed a contrived example of unrealistic code that we then showed to be simplified by pattern matching.  That's not the case: it really is just a simple educational example to present the idea.

BTW: as a matter of course, it is constructed in favour of the PEP!


> There seem to be three things you want to enhance here:
> Unpacking; to avoid calls to `len`
> Type checking; to avoid calls to `isinstance`.
> To avoiding nesting by using complex lvalues.

Actually, no.  Pattern matching is not about _avoiding_ anything, it is about a more concise syntax.  The suggestion that we wanted to avoid calls to `len` or `isinstance` is similar to the idea of using a lambda to avoid a function.  The objective of pattern matching is to introduce a more succinct and readable way to express structure.  It's all still there but we want to focus on the structure rather than `isinstance` calls.

Pattern matching already exists in some limited way in Python.  Even today you can write:
  `a, b = value`

instead of:
  `a = value[0]
   b = value[1]`
   
The idea of this is, of course, not so much about avoiding item access, but about having a more concise syntax for it.  Moreover, saying this only saves a single line and is therefore rather useless is quite beside the point.  It is about a better representation of what the code is supposed to do and not about saving lines.


> Saves two lines of code, but introduces two bugs!
> (Assuming that the original behavior should be preserved)

Thank you for pointing out the bug in our example.  This highlights, however, rather the difficulty of refactoring (did I already mention the issue of the 'context' that real code is embedded in?), than any shortcoming of pattern matching as a tool.  And by the way: constructive critisism would perhaps include explicitly naming the two bugs.


> For example, by adding a simple "matches" method to Node and Leaf, `is_tuple` can be rewritten as something like:

This assumes that you have full control over the entire code.  But if you are using some third-party library, you cannot "simply add a `matches` method" (without some substantial trickery).  Moreover, there is quite some work needed to define such a `matches` function as you propose it (including support for the ellipsis as wildcard).  In effect, you would have to implement large parts of the pattern matching for just this simple example.  Whereas we believe that it has merit enough to have the compiler do it for a wide range of possible use cases.


> I really don't see you how you can claim that
> `case 406:`
> is more readable than
> `elif response == HTTP_UPGRADE_REQUIRED:`
> ?
> Preventing the use of symbolic constants or other complex rvalues is a impairment to usability.

First, let me quote what the PEP has to say on that exact example:

> Although this will work, it's not necessarily what the proposal is focused on.

Moreover, it is usually a good idea to put constants into a separate namespace that further describes their meaning and intended use.  And that is fully supported by the syntax as proposed in the PEP.
```
match response.status:
    case HTTP_RESPONSE.UPGRADE_REQUIRED:
        ...
```



> 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.
>
> IMO, PEP 622 fails on both counts.

This seems fair enough as far as the two issues are concerned.  It might seem indeed as if pattern matching does not add anything that could not be done already in Python.  Part of the problem is that pattern matching starts to really shine when the objects and data get more complex---which requires a lot of built-up and context just to get to the point.  This is similar to OOP: as long as you stick with the easy introductory examples, OOP does not really provide anything that you could not solve using procedural programming.  For instance, I often see critisism of Java based on some simple hello-world examples, which completely misses the point of OOP in the first place, of course.

As far as referring to the best solution: may I humbly point out that pattern matching has been around for some 40 years now and has been adopted by an increasing number of languages lately.  We put a lot of effort into designing a version of it that fits well with Python and covered a huge design space, while also taking all the lessons of those who came before us to heart.  This is not just a new feature we propose on a whim.

In the end, pattern matching is an increasingly popular feature that favours higher-level declarative expressiveness over spelling out all the details of how to check the structure of data and extract information from it.  Think of it perhaps this way: pattern matching is like introducing grammars and parser generators instead of writing a new parser each time.  It answers the question of: could we have something like regular expressions for graph-like objects instead of only text...?


Kind regards,
Tobias