[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: https://github.com/python/cpython/blob/d2f305dfd183025a95592319b280fcf4b20c8694/Lib/concurrent/futures/_base.py#L583 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-114153
• gh-114164
• gh-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