On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen <elliottchen2...@gmail.com> wrote:
> I guess it might work in a separate PEP, but I'm also a little worried > because the current PEP would make that impossible with its subtle > incompatibilities with the existing unpacking syntax. Or even more > inconsistent, if the assignment target syntax is extended to become similar > to the match syntax but still slightly different for backwards > compatibility. > In my view 1 = x is a sneaky degenerate case, and what we should really be asking is if it's cool to be able to do, say, (x, 0) = a compared with "x, y = a; if y != 0: raise ValueError". BTW, +100% to the idea that match should extend assignment semantics (e.g. to allow multiple clauses). The totally new match semantics have come up a lot when I discussed this PEP with my friends at work. Even if we get awkward corner cases out of unifying the two, the simplicity of only having one notion of lvalue, instead of two lvalue-like things, is IMO an overriding benefit. This is also more or less how match and assignment tend to work in the languages that have pattern matching, . If we are repulsed by "1 = x" and (x, 0) = y, one solution is to do what Rust did and forbid refutable patterns on the left-hand side of an assignment, but allow them on the left hand side of a match case. (With the historically-minded exception of list and tuple literals). This still makes match an extension of assignment (it's assignment + multiple cases + refutable patterns) and gives us the simplicity benefits, while forbidding "1 = x". -- Devin
_______________________________________________ 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/IM6NZJSZHID46K3QYGG4GUJ5D6GMMX4P/ Code of Conduct: http://python.org/psf/codeofconduct/
