I was rather disappointed when I saw the final(?) state (or at least now accepted state) of the Pattern Matching PEPs the other day. I could write a rant now bu

I was rather disappointed when I saw the final(?) state (or at least now accepted state) of the Pattern Matching PEPs the other day. I could write a rant now but given the fact that pattern matching was a hotly debated[0] feature proposal, I assume my complaints must have all been considered at some point and there were good reasons to still go with the present PEPs. Unfortunately, there's little to no sign of this debate in PEPs 634, 635 and 636, so I hope some Core Developer will see my comment and have answers? Maybe then I'll make piece with this new feature. 1. Why not make patterns objects like pretty much everything else in Python (in particular: types, context managers, etc.)? I'm disappointed that it will be impossible to re-use patterns. 2. Why is the syntax for placeholders the same as for variables in usual Python expressions? Why not go with with `?placeholder` or `$placeholder`? I'm aware of the "symmetry" between construction and deconstruction that PEP-635 mentions[4] but in this case I find it rather disadvantageous: It will now be extremely cumbersome to insert constants into a pattern, as it will have to be done either through guards[1] or through attribute access[2]. More importantly, though, Python's syntax has now become extremely confusing over night – some identifiers in the pattern refer to placeholders, some others to existing variables. Sure, this is no different in function declarations that include type hints and default values. But the syntax here is a lot more complex and there is no clear line of separation as with function calls where the ":" and "=" tokens make it clear which identifiers are placeholders and which are existing objects. I am aware that PEP 640[3] was rejected but was it because of the question mark syntax or because of the fact that it tried to change lots of language features at once with no real benefit? (I myself would have rejected it for that reason, too.) 3. What was the idea behind overloading the class/constructor syntax as in `match [str(my_string_placeholder), foo]`? I can think of a lot alternatives and I have yet to find one that I find as confusing as this one. 4. Coming back to the idea from 1) of making patterns ordinary objects, such an object would basically be… a type. Or, put differently, pattern matching amounts to structural type checking plus the matching part. But Python already has structural typing through type hints, generic types and Protocols. The only drawback – apart from a couple pitfalls with Protocols – is that it is still impossible to use isinstance() to do check against generic types. My personal impression, though, is that a lot of people want that feature and that it will ultimately arrive. Or at least this is my hope. Then, however, we will have two ways to do structural type checks, which is clearly at odds with the Zen of Python. Did anyone consider this interplay of patterns vs. generic types? What will the future of generic types be? My complaint here is basically that the pattern matching PEP doesn't go far enough and that pattern matching on its own is a nice but rather niche feature. I think I would have liked a general way (or syntax) to describe the structure of objects in Python – but instead of improving the one existing way (type hints with generics and Protocols) we now have two suboptimal ways. [0]: https://lwn.net/Articles/845480/ https://lwn.net/Articles/845480/ [1]: https://www.python.org/dev/peps/pep-0635/#guards https://www.python.org/dev/peps/pep-0635/#guards [2]: https://www.python.org/dev/peps/pep-0635/#id24 https://www.python.org/dev/peps/pep-0635/#id24 [3]: https://www.python.org/dev/peps/pep-0640/ https://www.python.org/dev/peps/pep-0640/ [4]: https://www.python.org/dev/peps/pep-0635/#id28 https://www.python.org/dev/peps/pep-0635/#id28