On Sat, 31 Oct 2020 at 00:44, Mark Shannon <m...@hotpy.org> wrote: > Should match be an expression, or a statement? > ---------------------------------------------- > > Do we want a fancy switch statement, or a powerful expression? > Expressions have the advantage of not leaking (like comprehensions in > Python 3), but statements are easier to work with.
PEP 635 already includes a good rationale for using a statement in https://www.python.org/dev/peps/pep-0635/#the-match-statement > Can pattern matching make it clear what is assigned? > ---------------------------------------------------- > > Embedding the variables to be assigned into a pattern, makes the pattern > concise, but requires discarding normal Python syntax and inventing a > new sub-language. Could we make patterns fit Python better? > > Is it possible to make assignment to variables clear, and unambiguous, > and allow the use of symbolic constants at the same time? > I think it is, but PEP 634 fails to do this. This concern I agree with, and just posted PEP 642 as a proposal to address it by requiring an explicit syntactic prefix on any value lookups that occur in a match pattern. > How should pattern matching be integrated with the object model? > ---------------------------------------------------------------- > > What special method(s) should be added? How and when should they be called? > PEP 634 largely disregards the object model, meaning it has many special > cases, and is inefficient. PEP 642 eliminates at least some of the special cases. For the special cases that remain, I think we'll be OK to tackle generalisation as a "later" concern (similar to the way we lived without a Path-like protocol for a long time to allow objects other than strings in filesystem APIs). (As Brandt noted, the early iterations of PEP 622 did include a match customisation protocol, and the authors were persuaded to drop it and adopt a "Let's wait and see how far we get with just `__match_args__`, `__eq__`, and `ABC.register()` before adding anything else" approach instead) > The semantics must be well defined. > ----------------------------------- > > Language extensions PEPs should define the semantics of those > extensions. For example, PEP 343 and PEP 380 both did. > https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement > https://www.python.org/dev/peps/pep-0380/#formal-semantics > > PEP 634 just waves its hands and talks about undefined behavior, which > horrifies me. Is this in relation to the evaluation-order caveat, and the impact of using non-pure operations inside patterns? Even for with statements, we've tinkered with the exact timing of the __enter__ and __exit__ method lookups over the years in order to tweak exactly which exception gets thrown when both are missing (the original implementation followed the PEP in looking up "__exit__" first, as it used multiple CPython bytecodes, and wanted to be able to use "__enter__" immediately after loading it on to the stack. The current implementation instead looks up "__enter__" first, since that's the error users expect to see when both are missing, and we now have a dedicated SETUP_WITH opcode that made the change simple to implement). The problem with providing that level of specificity in PEP 634 is that fully mandating a specific evaluation order for all subpatterns and guard subexpressions means that potentially interesting optimisation opportunities for match statement evaluation could be ruled out. Even if the initial pattern matching implementation uses a straightforward top to bottom, left to right approach where each pattern is checked for a structural match, re-evaluating repeated subexpressions each time they appear, then its associated guard expression evaluated, it makes sense to allow for more clever implementations that aggressively cache repeated subexpressions in the structural matching patterns (which are supposed to be side-effect free, even though we have no way to enforce that restriction), and inspect the guard expressions for subclauses that can be evaluated early and potentially skip the full structural match if the guard clause becomes necessarily false (while abiding by the requirement that the guard expressions still follow normal left-to-right evaluation rules - the subexpression evaluations are just allowed to be interleaved with the evaluation of subpatterns in the structural matching part by a sufficiently capable compiler). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/EW3GQ5GLUXZKYCU672BXS46IYT57NAHJ/ Code of Conduct: http://python.org/psf/codeofconduct/
