Concerning my previous email,
Yes, my mistake. I'd forgotten (ironically) that the whole point is that it's an expression itself.
while (value:=get_next_pool_item()).in_use: print(value.refcount())
would be the appropriate analogue.
Consequently, my example is invalid. A better example would have been where one needs to access more than one attribute of the expression
while (node.x, node.y) > (5.0, 5.0) given node = get_neighbours(node): pass
This wouldn't be so easy to do without writing a lambda, or conditional break. Again, the example is completely arbitrary, simply there to indicate that moving the assignment out of the expression itself gives more scope for use. Hence, by superset, I meant that all cases using ":=" can be expressed with given, but not visa-versa.
Clearly the objectively best choice is "<-".
I'm convinced ;)
while (cmd := get_command()).token != CMD_QUIT:
I think this example is concise enough that it doesn't consider the readability when get_command is nontrivial.
If i'm refactoring this kind of code, or new to the module and attempting to unpick what is happening, I would argue that the latter example presents me with what I most care about up-front (the condition) and maybe care about (the implementation) second. Furthermore, the assignment is very obvious, which I think is quite important. I don't think that the ':=' approach is entirely cryptic, of course, I can read it. But I find the clarity in putting the expression before the assignment to be worthwhile. ---
A bit like how "strawman argument" is mostly used to mean "dammit, you just spotted an unwelcome consequence and/or flaw in my position which I have no counter too".
Not sure if this is directed at me (will assume so). I'm sure people misuse the term, but here I think it's appropriate. It doesn't quite fit the exact definition, I grant you, but arguing about character cost seems premature in the question of whether one should care about character cost (within reason). ---
:= would prevent you from using assignment expressions inside f-strings, which
could be argued is a good thing. Oh wow, that's rather interesting! I'll put it up there with "py2 f-strings as codecs". :)