Hello, Thanks for the reply. On Fri, 5 Feb 2021 13:32:25 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
On 2/5/2021 2:51 AM, Paul Sokolovsky wrote:
((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:pmiscml@gmail.com