gh-102757: fix function signature mismatch for functools.reduce between code and documentation

[XuehaiPan]

• Align function signature for functools.reduce in Python implementation and documentation with the C implementation.
• Add / to mark all arguments are positional only.

• Issue: Function signature mismatch for functools.reduce between C implementation, Python implementation, and online documentaion #102757

[XuehaiPan]

May also need to backport to Python 3.10 and 3.11. This documentation issue is causing real-world problems. Such as:

https://github.com/google/jax/blob/1703f096b5b7b66a1c97726c1c89ffdfbbfaaa22/jax/_src/tree_util.py#L274-L280

[arhadthedev]

@rhettinger (as a functools expert)

[carljm]

Thanks! It makes sense for the CPython
documentation and docstring of functools.reduce to align with the implementation that is always used in CPython.

[XuehaiPan]

Gentle ping for this. Any updates?

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 RHEL7 3.x has failed when building commit 74f315e.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/15/builds/5692) and take a look at the build logs.
4. Check if the failure is related to this commit (74f315e) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/15/builds/5692

Failed tests:

• test_socket

Failed subtests:

• test_dual_stack_client_v4 - test.test_socket.CreateServerFunctionalTest.test_dual_stack_client_v4

Summary of the results of the build (if available):

==

Click to see traceback logs

Traceback (most recent call last):
File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64/build/Lib/test/test_socket.py", line 6771, in test_dual_stack_client_v4with socket.create_server(("", port), family=socket.AF_INET6,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL7-x86_64/build/Lib/socket.py", line 935, in create_serverraise error(err.errno, msg) fromNoneOSError: [Errno 98] Address already in use (while attempting to bind on address ('', 57716))

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 RHEL8 LTO + PGO 3.x has failed when building commit 74f315e.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/568/builds/4853) and take a look at the build logs.
4. Check if the failure is related to this commit (74f315e) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/568/builds/4853

Failed tests:

• test.test_asyncio.test_unix_events

Failed subtests:

• test_fork_signal_handling - test.test_asyncio.test_unix_events.TestFork.test_fork_signal_handling

Summary of the results of the build (if available):

==

Click to see traceback logs

Traceback (most recent call last):
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/unittest/async_case.py", line 90, in _callTestMethodifself._callMaybeAsync(method) isnotNone:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsyncreturnself._asyncioTestContext.run(func, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/support/hashlib_helper.py", line 49, in wrapperreturn func_or_class(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_unix_events.py", line 1937, in test_fork_signal_handlingself.assertTrue(child_handled.is_set())
AssertionError: False is not true

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 RHEL8 LTO 3.x has failed when building commit 74f315e.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/64/builds/5081) and take a look at the build logs.
4. Check if the failure is related to this commit (74f315e) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/64/builds/5081

Failed tests:

• test.test_asyncio.test_unix_events

Failed subtests:

• test_fork_signal_handling - test.test_asyncio.test_unix_events.TestFork.test_fork_signal_handling

Summary of the results of the build (if available):

==

Click to see traceback logs

Traceback (most recent call last):
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto/build/Lib/unittest/async_case.py", line 90, in _callTestMethodifself._callMaybeAsync(method) isnotNone:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto/build/Lib/unittest/async_case.py", line 117, in _callMaybeAsyncreturnself._asyncioTestContext.run(func, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto/build/Lib/test/support/hashlib_helper.py", line 49, in wrapperreturn func_or_class(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/buildbot/buildarea/3.x.cstratak-RHEL8-x86_64.lto/build/Lib/test/test_asyncio/test_unix_events.py", line 1937, in test_fork_signal_handlingself.assertTrue(child_handled.is_set())
AssertionError: False is not true

[AA-Turner]

@carljm should we backport the docs part of this PR?

[carljm]

@AA-Turner Sure, we can. I don't think it's important, but I guess it's possible it could reduce conflict in some other backport in future.