This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: concurrent_futures semantics better specified in docs
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.6
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: F.D. Sacerdoti, bquinlan, docs@python, mark.dickinson, xtreak
Priority: normal Keywords:

Created on 2016-02-17 12:26 by F.D. Sacerdoti, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (7)
msg260396 - (view) Author: F.D. Sacerdoti (F.D. Sacerdoti) Date: 2016-02-17 12:26

My colleague and I have both written parallel executors for the concurrent_futures module, and are having an argument, as described in the dialog below. To resolve, I would like to add "order of results is undefined" to disambiguate the docs for "map(func, *iterables, timeout=None)".


Q: Correct Semantics to return results out of order?
JH: No, breaks API as stated
Rebut: order is undefined, concurrent_futures specifies map() returns an iterator, where builtin map returns a list. 
Q: Does it break the spirit of the module?
A: No, I believe one of the best things about doing things async is the dataflow model: do the next thing as soon as its inputs are ready.
 Q: Should we hold up the caller in all cases when there are stragglers, i.e. elements that compute slower?
 A: No, the interface should allow both modes.

def james_map(exe, fn, *args):
  return iter( sorted( list( fn, *args ) ) ) )
msg260477 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-02-18 18:57
The documentation says: "Equivalent to map(func, *iterables)". I believe that that equivalency implies that the ordering *is* defined, so it would be incorrect to add "order of results is undefined" to the documentation.
msg260478 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-02-18 19:00
Note also this code snippet from PEP 3148:

    for number, prime in zip(PRIMES,,

The use of zip here suggests strongly that the intention is that the order of the `map` result is well-defined.

It's possible that the docs should be updated to make the ordering requirement clearer.
msg260508 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-02-19 07:59
I just noticed this point, which may be confusing things:

> Rebut: order is undefined, concurrent_futures specifies map() returns an iterator, where builtin map returns a list.

In Python 3, the built-in map function returns an iterator, not a list.
msg326161 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2018-09-23 16:07
There were some improvements made that clarify differences between builtin map with and

msg341619 - (view) Author: Brian Quinlan (bquinlan) * (Python committer) Date: 2019-05-06 19:32
Can we close this bug then?
msg341623 - (view) Author: Karthikeyan Singaravelan (xtreak) * (Python committer) Date: 2019-05-06 19:42
I would propose closing since the original doc issue regarding order and map in Python 3 is resolved. Just to add there is a PR to make map less eager :
Date User Action Args
2022-04-11 14:58:27adminsetgithub: 70562
2019-05-06 19:43:33bquinlansetstatus: open -> closed
stage: resolved
2019-05-06 19:42:01xtreaksetmessages: + msg341623
2019-05-06 19:32:00bquinlansetmessages: + msg341619
2018-09-23 16:07:47xtreaksetnosy: + xtreak
messages: + msg326161
2016-02-19 07:59:55mark.dickinsonsetmessages: + msg260508
2016-02-19 07:52:09mark.dickinsonsetassignee: docs@python

components: + Documentation, - Library (Lib)
nosy: + docs@python
2016-02-18 19:00:01mark.dickinsonsetmessages: + msg260478
2016-02-18 18:57:06mark.dickinsonsetnosy: + mark.dickinson
messages: + msg260477
2016-02-18 18:50:44SilentGhostsetnosy: + bquinlan
components: + Library (Lib)
2016-02-17 12:26:30F.D. Sacerdoticreate