On Wed., 11 Nov. 2020, 8:10 am Brett Cannon, <br...@python.org> wrote:
> > > On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn <ko...@tobiaskohn.ch> wrote: > >> One of the simplest patterns is without doubt the literal pattern that >> essential only matches itself (e.g., ``case 123:`` or ``case >> 'abc':``). Any future unification of patterns and assignments would >> therefore necessarily allow for statement such as:: >> >> 1 = x >> > > I don't think that's true. There isn't anything that "necessarily" *has* > to happen; practicality beats purity. Thomas' statement is more about the > fact that there are so *many *concepts fully contained within the world > of pattern matching which do not apply outside of it. He didn't seem to > imply to me that *all* concepts had to be brought out to the general > language, just that there were ones that seem to make sense to pull out for > assignment unpacking. > And this is the view that PEP 642 takes as well: that we want to preserve the *option* of lifting aspects of pattern matching out to be more general, rather than committing up front to it always being an all-or-nothing proposition. For my mind, the flavour of assignment statement that I think would be the most plausible follow-up to matching against multiple patterns would take the form "try pattern = subject", and even accepting PEP 634 exactly as written wouldn't lock us out of that specific option. However the inferred constraint patterns would give me even more pause there than they do in the match statement proposals, so it would be nice to have the freedom to disallow them without reducing the overall expressiveness of the construct. There are limits to how much immediate complexity we'd want to incur to preserve that optionality (YAGNI and all that), but the way PEP 634 is currently defined creates *complications* that leak all the way from the parser through to the code generator, rather than building a cleaner conceptual abstraction layer at the AST level. Cheers, Nick. >
_______________________________________________ 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/2QK4OKHSG7EVARFWI2BHYMPZJFEIFGLK/ Code of Conduct: http://python.org/psf/codeofconduct/
