On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn <ko...@tobiaskohn.ch> wrote:
> 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 > 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. -Brett > > 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 > > > _______________________________________________ > 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/KOYU2FAY3DZ4EHYWR3FXBQMTDP72EEQQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/QZTD3OQRUI7SDQGJ6R5KZEWWK2KQT5IL/ Code of Conduct: http://python.org/psf/codeofconduct/
