The built-in function sum takes an optional argument "start" to specify what value to start adding from (defaults to 0). This argument should be a keyword argument in order to match the other built-in functions such as:

enumerate(range(10), start=5)

This patch allows users to write:

sum(range(10), start=5)

which previously raised "TypeError: sum() takes no keyword arguments". Since the only change is making an optional positional argument into a keyword argument, this has no effect on any existing code using the current convention of:

sum(range(10), 5)

This seems like a reasonable enhancement to sum to me.

Since 2.7 is in feature freeze, this can only apply to 3.7.

Lisa, would you like to take this one?

Adding this feature is so easy as moving '/' in Argument Clinic declaration one line up. I don't think it is worth to allow passing the first argument as a keyword argument.

Check what performance effect of this change on simple calls sum(()), sum((), 0).

I ran some timing tests of the patch I submitted to compare it to the current build of Python. Using timit on the current master branch I got:

python.exe -m timeit "sum(())"    .... 1.12 usec per loop
python.exe -m timeit "sum((), 0)" .... 1.22 usec per loop

And for the patched version:

python.exe -m timeit "sum(())"    .... 1.46 usec per loop
python.exe -m timeit "sum((), 0)" .... 1.57 usec per loop

However my patch wasn't just the simple argument clinic change suggested by serhiy.storchaka, so maybe that would be more efficient and easier to understand.

Your tests show that there is a performance regression of getting rid of Argument Clinic (in addition to increasing the maintenance cost of the code that was generated previously). Try to use the simple Argument Clinic change (it can has non-zero cost too, but I expect that its penalty is much smaller).

Hi Mark,

Are you able to make the Argument Clinic change the Serhiy suggested to come up with new benchmarks?

Thanks!

First than to allow this argument be passes by keyword, we mast choose its name. See the discussion "Start argument for itertools.accumulate()" on Python-ideas (https://mail.python.org/pipermail/python-ideas/2018-April/049649.html).

I don't think it is worth to allow passing the first argument as a keyword argument.

I concur. Would you mind to add a test to make sure that passing the first argument as the "iterable" keyword doesn't work?

"iterable" name comes from the Doc/library/functions.rst documentation and from the docstring.

In 2.6 it was "sequence".