If I was to do this in Python, rather than the Rust way of forbidding refutable patterns, I would put as a rule that the target must have at least one variable to bind* . It makes sense in the context that the goals of an assignment are the bindings it does, and the ValueError is an accident that the binding may be impossible sometimes. It would fit better with existing destructuring, and the python philosophy of trusting the developer and protecting the semantics with a runtime check.
* only allowing the historical () I mentioned earlier in the thread for compatibility with weird programs that no one ever wrote On Wed, 1 Jul 2020 at 23:24, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > 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/ >
_______________________________________________ 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/UK4BB72KOLGSUUYYJC5CN4PSMEP36XWV/ Code of Conduct: http://python.org/psf/codeofconduct/
