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
_______________________________________________
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/
