Hello,
Thanks for the reply. On Fri, 5 Feb 2021 13:32:25 -0500 Terry Reedy <[email protected]> wrote: > On 2/5/2021 2:51 AM, Paul Sokolovsky wrote: > > > https://www.python.org/dev/peps/pep-0572/ > ... > > >>>> ((a, b) := (1, 2)) > > File "<stdin>", line 1 > > SyntaxError: cannot use assignment expressions with tuple > > ---- > > > > Why this accidental syntactic gap? > > As should be clear from reading "Differences between assignment > expressions and assignment statements", this 'gap' in entirely > intentional, not accidental. *All* elaborations of 'name := > expression' are listed and rejected as outside the scope of the > proposal, which was to keep one reference to the expression value for > later use. At least some of these elaborations were suggested and > rejected during the voluminous discussion. And looking back now, that seems like intentionally added accidental gap in the language (https://en.wikipedia.org/wiki/Accidental_gap). Similar to artificially limiting decorator syntax, which was already un-limited. But seems, there're no "lessons learned", and there's now need to wait a decade again before fixing that? > The principal a.e. use in conditional expressions is testing for > non-nullness. Your > > > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > > a2 = a1 + 1 > > b2 = b1 + 1 > > is an unusual and very specific use. Well, many people were thinking (and I bet still think) that ":=" itself is very unusual case. But if it's in, why not make it consistent with the assignment statement and unleash the full power of it? > You want to have your tuple > (for subscripting for testing) and eat it too (by unpacking). That's good characterization, thanks. And Python syntax alone would allow to do that, if not extra-syntactical limitations put on top of it. > One can instead separate unpacking from testing a couple of ways > > while (tup := phi([a0, a2], [b0, b2]))[0] < 5: > a2, b2 = tup > a2 = a1 + 1 > b2 = b1 + 1 > > > while True: > a1, b1 = phi([a0, a2], [b0, b2]) > if a1 >= 5: break > a2 = a1 + 1 > b2 = b1 + 1 Right, but I started my original email with "I finally found a usecase where *not* using assignment expression is *much* worse than using it." Both conversions above apply additional disturbances to the original program, beyond pure SSA conversion, which is quite a disturbance on its own. I was really excited that Python 3.7+ would be *the* language which would allow to express SSA conversion faithfully on the source form of the high-level language (usually SSA is applied to low-level assembly-like intermediate representation). But oops, accidental gap, and despite all the Python advanceness, still need to apply workarounds as with other mundane languages. [] -- Best regards, Paul mailto:[email protected] _______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/X3LNCCO6PHTLAQXHEAP6T3FFW5ZW5GR5/ Code of Conduct: http://python.org/psf/codeofconduct/