With such a large new area of functionality that's at odds with existing syntax and semantics and a lack of clear vision and agreement, it
sounds like this would be better first added as a 3rd-party library to let the syntax and semantics mature. (To allow new syntax, it'll
probably be parsing strings in that special syntax.)

(At https://www.python.org/dev/peps/pep-0634/, there's no indication that this option was considered.)

On 06.02.2021 18:44, Mark Shannon wrote:
> 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-leave@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/

--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/
Code of Conduct: http://python.org/psf/codeofconduct/