This was intentional in PEP 572 so it is not a grammar bug fix.

Put your money where your mouth is, or become another armchair language designer. Your choice.

On Sun, Feb 7, 2021 at 23:58 Paul Sokolovsky <pmiscml@gmail.com> wrote:
Hello,

On Sun, 7 Feb 2021 13:10:55 -0800
Guido van Rossum <guido@python.org> wrote:

> Hi Paul,
>
> I suggest that you just go straight to the PEP phase.

Thanks. In all fairness, I don't expect immediate resolution to this
issue. But I'm aware of out for at least a year, and keep returning to
it (yes, in context of my SSA experiments). So, I proceeded to the next
stage - bring it up on its own, then created a bug ticket:
https://bugs.python.org/issue43143

And my idea is to try to argue that it would be just a "grammar
bugfix", similarly to already existing grammar elaborations for walrus:

https://bugs.python.org/issue42316
https://bugs.python.org/issue42374
https://bugs.python.org/issue42381

Granted, allowing "foo((a, b) := (b, a))" is a bit bigger change than
allowing "foo[a := b]" instead of "foo[(a := b)]". But if people
find assigning within index expression useful, up to reporting it, and
then other people ack it and fix it, then why not fix parallel
assignment case? Implementation-wise they *seem* to be of the
similar effort/complexity - just a one-term grammar change. (I still
need to run the testsuite, yeah).


>
> --Guido
>
> On Thu, Feb 4, 2021 at 11:54 PM Paul Sokolovsky <pmiscml@gmail.com>
> wrote:
>
> > Hello,
> >
> > Everyone knows how hard to find a compelling usecase for the
> > assignment expression operator (":=", colloquially "walrus
> > operator"). https://www.python.org/dev/peps/pep-0572/ examples
> > never felt compelling and we all remember the split it caused.
> >
> > I finally found a usecase where *not* using assignment expression is
> > *much* worse than using it. I'm working on SSA (Static Single
> > Assignment,
> > https://en.wikipedia.org/wiki/Static_single_assignment_form)
> > conversion of Python programs, where there's a need to "join"
> > dataflow of values from different control flow paths using a
> > special function (Phi function). This "joining" itself creates a
> > new variable, and of course, the original variable was used in an
> > expression. We've got assignment in expression, assignment
> > expression operator to the rescue!
> >
> > With it, a simple loop like:
> >
> > ----
> > a = 0
> > while a < 5:
> >     a += 1
> > ----
> >
> > becomes:
> >
> > ----
> > a0 = 0
> > while (a1 := phi(a0, a2)) < 5:
> >     a2 = a1 + 1
> > ----
> >
> > So far, so good. But semantics of Phi function is parallel
> > assignment. No problem with Python either, "a, b = b, c" is exactly
> > parallel assignment. So, let's try example with 2 variables:
> >
> > ----
> > a = 0
> > b = 10
> > while a < 5:
> >     a += 1
> >     b += 1
> > ----
> >
> > becomes:
> >
> > ----
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> >     a2 = a1 + 1
> >     b2 = b1 + 1
> > ----
> >
> > But oops:
> > 
> > > SyntaxError: cannot use assignment expressions with tuple 
> >
> > To reproduce in the REPL:
> >
> > ---- 
> > >>> ((a, b) := (1, 2)) 
> >   File "<stdin>", line 1
> > SyntaxError: cannot use assignment expressions with tuple
> > ----
> >
> > Why this accidental syntactic gap? Why assignment statement can do
> > parallel assignment with a tuple on LHS, and assignment operator
> > suddenly can't?
> >
> > Why the adhoc naming and conceptual shift on the AST level, when
> > PEP572 explicitly talks about *assignment operator*, but
> > corresponding node on the AST level is called NamedExpr? Why look
> > at assignment expression as "name of expression" instead of
> > assignment expression per se?
> >
> > It's of course not a problem to recast:
> >
> > NamedExpr(expr target, expr value)
> >
> > to
> >
> > NamedExpr(expr* target, expr value)
> >
> > in the ASDL (and it works out of the box), the point is that it
> > should have been ExprAssign from the start (folloing the AugAssign
> > and AnnAssign tradition).
> >
> >
> > --
> > Best regards,
> >  Paul                          mailto:pmiscml@gmail.com
> > _______________________________________________
> > 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/6IFDG7PAFPHVPGULANOQDAHP2X743HCE/
> > 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/>



--
Best regards,
 Paul                          mailto:pmiscml@gmail.com
--
--Guido (mobile)