[Doc] Wrong parameter name for `concurrent.futures.Executor.map(fn, ...)

[eddiebergman]

Documentation

Just noticed that in the published documentation, the concurrent.futures.Executor.map says it takes some parameter named func as the first argument, however the implementation has it as fn.

This is a strictly documentation issue and doesn't have non-introspected code related issues, as it's followed by an *iterables argument, preventing it from being used as a keyword.

Implementation:

cpython/Lib/concurrent/futures/_base.py

Line 583 in d2f305d

def map(self, fn, *iterables, timeout=None, chunksize=1):

CPython Doc: https://github.com/python/cpython/blob/d2f305dfd183025a95592319b280fcf4b20c8694/Doc/library/concurrent.futures.rst#executor-objects
Published docs: https://docs.python.org/3.12/library/concurrent.futures.html#concurrent.futures.Executor.map

I came across this while overwriting the Executor class and using the @override decorator which warned me that the naming is inconsistent.

Happy to provide a PR if needed.

Linked PRs

• gh-112043: Align concurrent.futures.Executor.map docs with implementation #114153
• [3.12] gh-112043: Align concurrent.futures.Executor.map docs with implementation (GH-114153) #114164
• [3.11] gh-112043: Align concurrent.futures.Executor.map docs with implementation (GH-114153) #114165

[terryjreedy]

Argument name mismatches between doc and code are allowed as harmless, though not desirable, for positional-only arguments of C-coded functions. But doc should match code for Python-coded functions. The mismatch here goes back the the original code and doc patch by Brian Quinlan on 10/4/2010. The submit method also has an 'fn' parameter after 'self', and it is documented as 'fn'.

I would have preferred 'func' in both code and doc for both methods, but I think here we should fix the doc for map(), There are several instances of 'func' to change. I think go ahead with a PR.

For the curious: typing.override