Hi, I'd like to request that any pattern matching PEP and its implementation meet certain standards before acceptance. As one of the maintainers of the AST-to-bytecode part of the compiler and the bytecode interpreter, I don't want to be in the situation where we are forced to accept a sub-standard implementation because a PEP has been accepted and the PEP authors are unable, or unwilling, to produce an implementation that is of a sufficiently high standard. Therefore, I would ask the steering committee to require the following as a minimum before formal acceptance of any pattern matching PEP. 1. The semantics must be well defined. 2. There should be no global side-effects in the bytecode. 3. Each bytecode should perform a single, reasonably limited, operation. 4. There should be a clear path, using known compiler optimization techniques to making it efficient, if it is not initially so. 1. We want to be able to change the implementation. The current (3.9+) compiler produces quite clean bytecode for "try-finally" and "with" statements. Earlier implementations of the compiler were simplistic and required quite convoluted bytecodes in the interpreter. We were able to make these improvements because the "try-finally" and "with" statements are well specified, so we could reason about changes to the implementation. Should the old and new implementations have differed, it was possible to refer to the language documentation to determine which was correct. Without well defined semantics, the first implementation of pattern matching becomes the de-facto semantics, with all of its corner cases. Reasoning about changes becomes almost impossible. 2. The implementation of PEP 634 can import "abc.collections" mid bytecode. I don't look forward to the bug reports when the module can't be imported for some unrelated reason and pattern matching fails. We recently added the `LOAD_ASSERTION_ERROR` bytecode to ensure that asserts work even after `del builtins.AssertionError`. We should maintain this level of robustness. 3. This comes down to reasoning about whether the compiler is correct, and interpreter performance. Admittedly, the current bytecodes don't always adhere to the above rule, but they mostly do and I don't want the situation to deteriorate. The implementation of PEP 634 includes a number of bytecodes that implement their own mini-interpreters within. It is the job of the compiler, not the interpreter, to handle such control flow. 4. If pattern matching is added to the language, and it becomes popular, we don't want it to be slow. Knowing that there exists an efficient implementation, and how to achieve it, is important. Ideally the initial implementation should be efficient, but knowing that it could be is sufficient for acceptance. Cheers, Mark.