[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
Ethan Furman
ethan at stoneleaf.us
Wed Apr 25 18:36:02 EDT 2018
More information about the Python-Dev mailing list
Wed Apr 25 18:36:02 EDT 2018
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 04/25/2018 03:15 PM, Ethan Furman wrote: > On 04/25/2018 02:55 PM, Tim Peters wrote: > >> 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. > > I know why I do: I see "while total != total" and my gears start stripping. On the other hand, > > while total != (total + term as total): > ... > > I find still intelligible. (Yes, I know "as" is dead, just wanted to throw that out there.) Having said that, since whomever mentioned reading ":=" as "which is", I'm good with ":=". -- ~Ethan~
- Previous message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Next message (by thread): [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list