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.