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/

Reply via email to