Why there is an optional `initial` parameter for `functools.reduce` function, but there is no such for `itertools.accumulate`, when they both are doing kind of similar things except that `itertools.accumulate` yields intermediate results and `functools.reduce` only the final one?

Presumably because conceptually an 'initial value' would be like adding an additional element on to the front of the iterable being passed as an argument, and itertools is all about operating on iterables.  I'm not saying such an argument could not be added, but the API is cleaner without it.

I'm open to adding the feature as a keyword-only argument.

Lisa, would you like to bring this to fruition?

Happy to! I'll try to make a patch.

This looks like a duplicate of issue25193.

See also a long discussion on the Python-ideas mailing list 5 months ago: [Start argument for itertools.accumulate()](https://mail.python.org/pipermail/python-ideas/2018-April/049649.html).

Tim, do we care about whether "initial=None" versus "initial=_sentinel"?

The former makes for a nice looking pure python equivalent and works nicely with the argument clinic to generate a signature.  However, it precludes using None as the actual start argument (though I don't see why somewone would want to do that), and it isn't parallel to reduce() (not sure I care about that at all). 

Kristjan, do you want to contribute to the update of the pickle/copy code for this API extension?

Ya, I care:  `None` was always intended to be an explicit way to say "nothing here", and using unique non-None sentinels instead for that purpose is needlessly convoluted.  `initial=None` is perfect.  But then I'm old & in the way ;-)

The first issue, with ignoring initial=None, is complex because Argument Clinic and the inspect module don't support optional parameters without default value. It could be possible to use optional groups, but currently Argument Clinic supports optional groups only when all parameters are positional-only. For now, the only way is getting rid from Argument Clinic.

As for pickling/copying, this task is technically difficult, it but I don't see principal problems. The code is already complex (see issue25718) and will be more complex. Since the reduce protocol doesn't support keyword arguments, we will needs to use either partial() for passing the keyword argument, or chain() for imitating it by creating an equivalent object. I can write this code.

Taking to the account the complexity of the implementation and arguments against this feature (see issue25193 and the discussion on Python-ideas), is it worth to add it?

I think I'll pass Raymond, its been so long since I've contributed, in the mean time there is github and argument clinic and whatnot so I'm out of training.  I´m lurking around these parts and maybe shall return one day :)

> As for pickling/copying, this task is technically difficult, 
> it but I don't see principal problems. 

I've added the pickle/copy support to the PR.

> is it worth to add it?

Tim was persuasive, so I've agreed to add the feature.  It may be little used but may help once in a while.

New changeset 9718b59ee5f2416cdb8116ea5837b062faf0d9f8 by Lisa Roach in branch 'master':
bpo-34659: Adds initial kwarg to itertools.accumulate() (GH-9345)
https://github.com/python/cpython/commit/9718b59ee5f2416cdb8116ea5837b062faf0d9f8