Just a nit here: [Tim] >> ... >> Arguing that it "has to do" something exactly the way `sum()` happens >> to be implemented just doesn't follow - not even if they happen to >> give the same name to an optional argument. If the function were >> named `accumulate_sum()`, and restricted to numeric types, maybe - but >> it's not.
[Nick] > When first added in 3.2, it did have that restriction, and the default > behaviour without a function argument still parallels repeated use of > the sum() builtin. They're not quite the same today. For example, if you have an object `x` of a custom numeric class, sum([x]) invokes x.__radd__ once (it really does do `x.__radd__(0)`), but list(itertools.accumulate([x])) just returns [x] without invoking x.__add__ or x.__radd__ at all. > Extending the parallel to *also* include a parameter called "start" > would create the expectation for me that that parameter would adjust > the partial result calculations, without adding an extra result. > > Other parameter names (like the "first_result" I suggested in my reply > to Guido) wouldn't have the same implications for me, so this > objection is specific to the use of "start" as the parameter name, not > to the entire idea. Yup! That's fine by me too - and preferable even ;-) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/