[issue32306] Clarify map API in concurrent.futures

2017-12-21 Thread David Lukeš
David Lukeš added the comment: Perfect, thanks! -- ___ Python tracker ___ ___

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Antoine Pitrou
Antoine Pitrou added the comment: I think the documentation is now clearer. Closing! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Antoine Pitrou
Antoine Pitrou added the comment: New changeset 4aa84e728565a15a82727b9b971126e355f47e9d by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-32306: Clarify c.f.Executor.map() documentation (GH-4947) (#4948)

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Roundup Robot
Change by Roundup Robot : -- pull_requests: +4840 ___ Python tracker ___

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Antoine Pitrou
Antoine Pitrou added the comment: New changeset a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d by Antoine Pitrou in branch 'master': bpo-32306: Clarify c.f.Executor.map() documentation (#4947) https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Antoine Pitrou
Change by Antoine Pitrou : -- keywords: +patch pull_requests: +4839 stage: -> patch review ___ Python tracker ___

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread David Lukeš
David Lukeš added the comment: Yes, sorry for not being quite clear the first time around :) I eventually found out about Pool.imap (see item 3 on list in OP) and indeed it fits my use case very nicely, but my point was that the documentation is somewhat misleading

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread Antoine Pitrou
Antoine Pitrou added the comment: I see. So the problem you are pointing out is that the tasks *arguments* are consumed eagerly. I agree that may be a problem in some cases, though I think in most cases people are concerned with the *results*. (note that

[issue32306] Clarify map API in concurrent.futures

2017-12-20 Thread David Lukeš
David Lukeš added the comment: Hi Antoine, Thanks for the response! :) I think the problem lies in the line immediately preceding the code you've posted: ``` fs = [self.submit(fn, *args) for args in zip(*iterables)] ``` In other words, all the jobs are first

[issue32306] Clarify map API in concurrent.futures

2017-12-19 Thread Antoine Pitrou
Antoine Pitrou added the comment: Hi David, > what happens behind the scenes is that the call blocks until all results are > computed and only then starts yielding them. The current implementation of the Executor.map() generator is: def result_iterator():

[issue32306] Clarify map API in concurrent.futures

2017-12-13 Thread David Lukeš
New submission from David Lukeš : The docstring for `concurrent.futures.Executor.map` starts by stating that it is "Equivalent to map(func, *iterables)". In the case of Python 3, I would argue this is true only superficially: with `map`, the user expects