Remove ambiguous part in docstring of functools.reduce()

[rabelux]

To me the description of functools.reduce() sounded like initial will only be used if iterable is empty. This is not the case. Plus I included one additional sentence that was present in https://docs.python.org/3/library/functools.html#functools.reduce but not the docstring.
If this PR gets approved I suggest to also adapt the html-docs accordingly.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[picnixz]

This would also require to change the C extension module:

cpython/Modules/_functoolsmodule.c

Line 1042 in a852c7b

_functools.reduce

. The pure Python implementation is just a fallback in case the C implementation is not available. Also, I think it's better for the docstring to be concise, though there is an example inside the docstring so maybe we can be a bit more verbose.

cc @rhettinger

[rabelux]

Please let me know what you'd prefer.
I can either remove the last two sentences and adapt the c-file accoringly, or you're happy with the way it is phrased and I'll update the c-file, or you want a completely different solution and take it from here?
At least I hope you agree that the current wording can be misunderstood.

[picnixz]

Personally, I think the wording is fine so I would rather not change anything. I understand the "and serves as a default when the iterable is empty" as "in particular, it serves as a default value when the iterable is empty". IOW, it's not its only role. But the new wording would remove any pre-assumption that the reader may have so it's also fine. What matters is that if we change the docstring, then we need to change the docstring at the C level as well.

I don't have any thing I want personally, and I'd rather defer this to Raymond.

[rhettinger]

Personally, I think the wording is fine so I would rather not change anything.

I concur that the current wording is clear enough (and it matches the code equivalent that follows.

@rabelux Thanks for the suggestion, but we will decline.