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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RUMVGTKTMSNDOT3LTWN4ZLVFN2F6E4YO/
Code of Conduct: http://python.org/psf/codeofconduct/
