We're trying to make the PEP's scope *smaller*, not larger. Let's take changes to assignment off the table. We're fully aware of the resemblance between `a, b = value` and `case a, b: ...` and we're making them behave as similar as is reasonable.
On Wed, Jul 1, 2020 at 4:29 PM Daniel Moisset <dfmois...@gmail.com> wrote: > 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/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/FD6PC3JTHDQAYQBBVLYLMPCZMGTHWTWW/ Code of Conduct: http://python.org/psf/codeofconduct/
