Hi all, thank you for the feedback. I laughed, I cried, and I learned.
I looked over all your suggestions and recreated them here:
I still favour my (y = f(y, x) for x in xs from y=initializer) syntax for a few reasons:
1) By adding an "initialized generator" as a special language construct, we could add a "last" builtin (similar to "next") so that "last(initialized_generator)" returns the initializer if the initialized_generator yields no values (and thus replaces reduce).
2) Declaring the initial value as part of the generator lets us pass around the generator around so it can be run in other scopes without it keeping alive the scope it's defined in, and bringing up awkward questions like "What if the initializer variable in the scope that created the generator changes after the generator is defined but before it is used?"
3) The idea that an assignment operation "a = f()" returns a value (a) is already consistent with the "chained assignment" syntax of "b=a=f()" (which can be thought of as "b=(a=f())"). I don't know why we feel the need for new constructs like "(a:=f())" or "(f() as a)" when we could just think of assignments as returning values (unless that breaks something that I'm not aware of)
However, it looks like I'd be fighting a raging current if I were to try and push this proposal. It's also encouraging that most of the work would be done anyway if ("Statement Local Name Bindings") thread passes. So some more humble proposals would be:
1) An initializer to itertools.accumulate
functools.reduce already has an initializer, I can't see any controversy to adding an initializer to itertools.accumulate
2) Assignment returns a value (basically what's already in the "Statement local name bindings" discussion)
`a=f()` returns a value of a
This would allow updating variables in a generator (I don't see the need for ":=" or "f() as a") but that's another discussion
Is there any interest (or disagreement) to these more humble proposals?
- Peter