> Well if you can get Raymond to agree on that too I suppose you can go ahead.
> Personally I'm -0 but I don't really write this kind of algorithmic code
> enough to know what's useful.

Actually, you do - but you don't _think_ of problems in these terms.
Neither do I.  For those who do:  consider any program that has state
and responds to inputs.  When you get a new input, the new state is a
function of the existing state and the input.  That's `accumulate`!
It generates a sequence of new states as the sequence of incrementally
updated states derived from a sequence of inputs according to the
function passed to accumulate.

In that view of the world, specifying a starting value is merely
specifying the program's initial state - and from that view of the
world, not allowing to specify a starting value is bizarre.

While Will Ness's wheel sieve program, and my Collatz
glide-record-finder, don't _derive_ from that view of the world, it
turns out that specifying (and returning) an initial value is also
useful for them, and despite that they're just doing integer running

A simple example from the broader view of the world is generating all
the prefixes of a list:

>>> from itertools import *
>>> list(accumulate(chain([[]], [8, 4, "k"]), lambda x, y: x + [y]))
[[], [8], [8, 4], [8, 4, 'k']]

That's obviously easier to follow if written, e.g.,

list(accumulate([8, 4, "k"], lambda x, y: x + [y], first_result=[]))

> I do think that the new parameter name ["first_result"] is ugly. But maybe 
> that's
> the point.

I noted later that the `accumulate` in the Python itertoolz package
names its optional argument "initial".  That's not ugly, and works
just as well for me.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to