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 <dfmoisset@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 <jeanpierreda@gmail.com> wrote:
On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen <elliottchen2004@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-leave@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-leave@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?)