Hi Thomas, Thank you very much for your carefully worded and thoughtful email. I feel, however, that many of your concerns are based on an idealised picture of a future Python language that will never actually materialise. As I understand it your main point is that the concept of patterns might---or even should---be retro-fitted to general assignments. Just as we have borrowed from and expanded on the idea of iterable unpacking in assignments, so should assignments then pick up the concepts introduced in pattern matching. Indeed, assignments of the form ``Viking(spam, ham) = ...`` are not only appealing but can be found in various languages with pattern matching. So, why would we not want to have consistent concepts and symmetric (orthogonal) structures across all of Python? Unfortunately, such consistency or symmetry comes at a high cost---too high as far as I am concerned. 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 This is essentially equivalent to ``assert(x == 1)``. Indeed, _Elixir_ [1] uses such syntax for exactly this semantics. However, knowing how much novice programmers struggle with understanding that assignments are right-to-left (i.e. ``x = 1`` and not ``1 = x``), including such syntax would immediately raise the learning curve significantly. In short, a very common students' mistake will take them to error messages and concepts they could not possibly understand without a basic comprehension of pattern matching. And this is probably where it becomes most obvious how our views of pattern matching differ. The pattern matching as we propose it in PEPs 634/635/636 is guarded by a keyword needed to activate these features. Unless you start your statement with ``match my_data:``, you can easily pretend as if pattern matching did not exist: it will not, cannot affect your code. This encapsulation is intentional and by design. As far as I am aware, those languages that support syntax like ``Viking(spam, ham) = ...`` only allow this in combination with variable _declaration_, i.e. you actually have to write ``let Viking(spam, ham) = `` or ``var Viking(spam, ham) = ...`` or similar. Without such a marker, this syntax quickly descends into unreadable gibberish. As noted in the original section of rejected ideas in PEP 622, we had originally considered adding 'one-off pattern matching': pattern matching with only a single case that must succeed, very much like normal assignments do. But our approach was always guarded by a keyword, be that ``case`` or ``if``---in line with the ``var`` or ``let`` found in other languages. Even in that case, patterns would not leak into the language outside pattern matching. Finally, there is already a necessary inconsistency between iterable unpacking and pattern matching. By their very nature, patterns express a _possible_ structure, whereas iterable unpacking imposes a _necessary_ structure. So, when dealing with iterators, it is safe to 'unpack' the iterator in iterable unpacking. If the expected and actual structures differ, it is an error, anyway. In pattern matching, however, we have to be more conservative and careful, exploring options rather than certanties. Hence, even if all other concerns were wiped away, the closest we could come to an entirely symmetric and consistent language is one with some subtle differences and thus prone for bugs and errors. PEPs 634/635/636 are the result of a long and careful design process where we sought to appeal to the intuition of the Python programmer as much as possible, without betraying the differences and new concepts that pattern matching necessarily introduces. Readability was always one of our main concerns and we believe that having a clear context where patterns occur greatly helps writing readable and consistent code. So, long story short, I am afraid I would question the very premise upon which your concerns are founded: that it would ever be a good idea to expand patterns to assignments in general. Although such a unification was in principle possible, it would rob Python of one of its greatest and strongest assets: its simplicity and learnability. Kind regards, Tobias [1] https://elixir-lang.org/getting-started/pattern-matching.html