You don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you.
[Łukasz Langa firstname.lastname@example.org]
This reads dismissive to me. I did read the PEP and followed the discussion on python-dev. I referred to PEP 20 because it distills what's unique about the value proposition of Python. It's our shared vocabulary.
Can you address the specific criticism I had? To paraphrase it without PEP 20 jargon:
(name := expression) makes code less uniform. It inserts more information into a place that is already heavily packed with information (logic tests).
I'll take a crack at that. It's not about "head arguments" at all. I sat out the first hundred messages about this on python-ideas, and looked at code instead. What I found had little to do with any of the head (abstract) arguments passionately debated for the duration ;-)
In real life, I found a great many conditional tests that not only weren't "heavily packed" with information, they were simply of the form:
NAME = expression if NAME: ... use NAME ...
That looks more like assembly language than Python ;-) I saw no harm at all, and a little gain, in
if NAME := expression: ... use NAME ...
instead. But even a little gain adds up when it happens so often.
Of course there have been better examples given of bigger gains. But in no case have the tests in those examples been "heavily packed with information". If they had been, I would have suggested instead breaking the test clauses _out_ of the conditional statements, and giving them names each on their own dedicated lines, with comments explaining what the heck the _intents_ are, even at the cost of adding an indentation level or two. Sometimes conditionals are _already_ "too dense". But more often they're very sparse.
This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough pattern in code slinging floats or decimals):
while True: old = total total += term if old == total: return total term *= mx2 / (i*(i+1)) i += 2
To my eyes, this is genuinely harder to follow, despite its relative brevity:
while total != (total := total + term): term *= mx2 / (i*(i+1)) i += 2 return total
So I wouldn't use binding expressions in that case. I don't have a compelling head argument for _why_ I find the latter spelling harder to follow, but I don't need a theory to know that I in fact do.
But neither do I need a compelling head argument for "why" to know that in many other cases I find that the use of binding expressions improves the code. You shouldn't believe me even if I pretended to have one and passionately argued for it. But, by the same token, I'm spectacularly unmoved by other peoples' head arguments.
For that reason, the messages that sway me are those showing real code, or at least plausibly realistic code. In the majority of those so far, binding expressions would be a small-to-major win.