Closed eddiebergman closed 9 months ago
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
Documentation
Just noticed that in the published documentation, the
concurrent.futures.Executor.map
says it takes some parameter namedfunc
as the first argument, however the implementation has it asfn
.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