[issue26374] concurrent_futures Executor.map semantics better specified in docs

Karthikeyan Singaravelan added the comment: 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 : https://github.com/python/cpython/pull/707/ --

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Change by Brian Quinlan : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Brian Quinlan added the comment: Can we close this bug then? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Karthikeyan Singaravelan added the comment: There were some improvements made that clarify differences between builtin map with https://bugs.python.org/issue32306 and https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d Thanks -- nosy: +xtreak

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Mark Dickinson added the comment: 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.

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Changes by Mark Dickinson : -- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python ___ Python tracker

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Mark Dickinson added the comment: Note also this code snippet from PEP 3148: for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)): The use of zip here suggests strongly that the intention is that the order of the `map`

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Mark Dickinson added the comment: 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. -- nosy: +mark.dickinson

[issue26374] concurrent_futures Executor.map semantics better specified in docs

Changes by SilentGhost : -- components: +Library (Lib) nosy: +bquinlan ___ Python tracker ___

[issue26374] concurrent_futures Executor.map semantics better specified in docs

New submission from F.D. Sacerdoti: Hello, 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