Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@aisk

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

@aeros

@aisk

Thanks for the contribution to CPython project :)
Glad to meet you again on GitHub.
Would you like to sign up for the CLA, please?

@corona10 Hi thanks for your welcome! Happy to see you again!

The CLA is signed, and I think it's taking time to complete? The bot said it's taking a work day usually.

The CLA is signed, and I think it's taking time to complete? The bot said it's taking a workday usually.

Yes, it is expected to take some time. Let's wait until then. :)
I request the final review to the core developer.

If you need my help please ping me any time

Thanks for your contribution!

😃 Thank you again!

Updated, and the CLA check is passed.

Dear @rhettinger

This PR is the @aisk 's first time contributing to this project.
Can you please take a look at this PR as the core developer?
Triagers reviewed it already, only left is the core developer's decision. :)
Thank you for your understanding.

Sorry, I'm going to recommend rejecting this edit as being unnecesary. The argument signature already shows that only one iterable is accepted.

AFAICT, no one has ever been confused by the current docs. There has been interest in changing the signature to accommodate multiple inputs, but that is a different matter than whether the current docs are accurate.

@rhettinger Hi I'm fine with this, and have another question. If we change the signature to allow it accept multiple iterable as input, how to compat with old codes? Some developer could call this with chunksize without keyword argument like pool.map(func, iterable, 10).

Can we just check the chunksize's type and make it compatible? or mark it as a breaking change?

@rhettinger

Sorry, I'm going to recommend rejecting this edit as being unnecesary. The argument signature already shows that only one iterable is accepted.

While there's already mention of pool.map() only accepting one iterable, I think it's helpful to briefly mention and link to pool.starmap() as an alternative for multiple iterables. @berkerpeksag suggested mentioning this in the bpo issue, which seems to be the primary purpose of the PR:

I think we can add a note for starmap() in the following sentence:

[...] (it supports only one iterable argument though).

Perhaps the PR could be edited to leave the existing "supports only one iterable" part intact, and modify it only slightly to mention pool.starmap() (which is more along the lines of @berkerpeksag's suggestion):

      A parallel equivalent of the :func:`map` built-in function (it supports only
      one *iterable* argument though, for multiple iterables see :meth:`starmap`).
      It blocks until the result is ready.

Also, it might be helpful to obtain additional input on this from @pitrou, since he's an active expert/maintainer for the multiprocessing module.

I'd be in favour of @aeros' proposed change. Feel free to open a new PR :-)

@pitrou

I'd be in favour of @aeros' proposed change. Feel free to open a new PR :-)

Awesome, sounds good. (:

@aisk Let me know if you'd like to open a PR with the above recommended changes (or simply open it and @ mention me).

@aeros ok, I'll try it later this day, thanks!