Hi,
Since a decision on PEP 634 is imminent, I'd like to reiterate some
concerns that I voiced last year.
I am worried about the semantics and implementation of PEP 634.
I don't want to comment on the merits of pattern matching in general, or
the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
Semantics
---------
1. PEP 634 eschews the object model, in favour of adhoc instance checks,
length checks and attribute accesses.
This is in contrast to almost all of the the rest of the language, which
uses special (dunder) methods:
All operators,
subscripting,
attribute lookup,
iteration,
calls,
tests,
object creation,
conversions,
and the with statement
AFAICT, no justification is given for this.
Why can't pattern matching use the object model?
PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
to the object model, and that works very well.
2. PEP 634 deliberately introduces a large area of undefined behaviour
into Python.
https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
Python has, in general, been strict about not having undefined behaviour.
Having defined semantics means that you can reason about programs, even
non-idiomatic ones.
[This is not unique to Python, it is really only C and C++ that have
areas of undefined behaviour]
I can see no good reason for adding undefined behaviour. It doesn't help
anyone.
The lack of precise semantics makes programs harder to understand, and
it makes the language harder to implement.
If the semantics aren't specified, then the implementation becomes the
specification.
This bakes bugs into the language and makes it harder to maintain,
as bug-for-bug compatibility must be maintained.
3. Performance
PEP 634 says that each pattern must be checked in turn.
That means that multiple redundant checks must be performed on (for
example) a sequence if there are several mapping patterns.
This is unnecessarily slow.
Implementation
--------------
My main concern with the implementation is that it does too much work
into the interpreter.
Much of that work can and should be done in the compiler.
For example, deep in the implementation of the MATCH_CLASS instruction
is the following comment:
https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
Such complex control flow should be handled during compilation, rather
than in the interpreter.
Giant instructions like MATCH_CLASS are likely to have odd corner cases,
and may well have a negative impact on the performance of the rest of
the language.
It is a lot easier to reason about a sequence of simple bytecodes, than
one giant one with context-dependent behaviour.
We have spent quite a lot of effort over the last few years streamlining
the interpreter.
Adding these extremely complex instructions would be a big backward step.
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/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
Code of Conduct: http://python.org/psf/codeofconduct/
