Hello all, 

The official doc describes `Pool.map(func, iterable[, chunksize])` as "A parallel equivalent of the map() built-in function.". 

Since the function signature of `map` is `map(function, iterable, ...)`, I hereby suggest that `Pool.map` should change its function signature to `Pool.map(function, iterable, ... [, chunksize])`. This will bring true equivalent to these functions. 

Tell me what you think. 

Pool.map: https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.map 

map: https://docs.python.org/3/library/functions.html#map 

Jason

-0 We need better motivation than "that is was map() does".  Instead, are should look at whether there are compelling use cases and its impact on the complexity of the multiprocessing implementation.  I usually just prezip my data and it works fine.

Note that `Pool` grew `starmap()` and `starmap_async()` methods in Python 3.3 to (mostly) address this.

The signature difference from the old builtin `map()` remains regrettable.  Note that the `Pool` version differs from the `concurrent.futures` version of `map()` in this respect too.

It would be helpful if the docs at https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.map and in `help(Pool.map)` mentioned starmap in a "see also" section at the bottom.

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

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

(Quoted from https://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.map)

Would you like to write a patch?

Happy to. What is the process? hg clone cpython, and make a patch from that and post it here? Or is there some pull-request style process available?

> What is the process? hg clone cpython, and make a patch from that and post it here?

Yes, it's exactly what you just described :) See https://docs.python.org/devguide/index.html for details.

> Or is there some pull-request style process available?

Not yet, but we will move to GitHub soon.

OK, one question, is Pool.map preferable to Pool.starmap in any particular cases?

Here you go.

@naught101: Thanks for the wording change -- I think your suggested doc change will be a good one.  I've added a comment which you can access via the "review" link to the right of the link for your mp.map.starmap.patch attachment.

Are you going to open a PR for this patch? I think that would be a nice addition

Hey,

Is it still open?
What else needs to be done?

Ido

> Is it still open? What else needs to be done?

Yes, this patch needs to be translated into a GitHub PR. See https://devguide.python.org/pullrequest/ for more information on our PR workflow if you're not already familiar with it. Since naught101 wrote a patch, we should have their name in "Co-Authored-By" of the final commit to the PR if they have a GitHub account. If not, just mention it in a comment to the PR that they originally wrote the patch. 

Feel free to @mention me when you open the PR so I can help to review it, although this will likely require a final approval from a maintainer of multiprocessing module before it can be merged.