<div dir="ltr"><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">Hello,</span><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote" style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">

<div dir="ltr"><div><br></div>It may be interesting to highlight that multiprocessing handles this by providing a <a href="http://docs.python.org/3/library/multiprocessing.html#multiprocessing.pool.Pool.imap_unordered" target="_blank">imap_unordered function</a>.<div>

<br></div><div>I provide an interface compatible to the futures (<a href="http://www.python.org/dev/peps/pep-3148/" target="_blank">PEP-3148</a>) in my parallel framework (<a href="http://scoop.googlecode.com/" target="_blank">SCOOP</a>) and I also feel the need for a simple way to iterate through results as they are completed.<br>

I understand that the <i>map()</i> function should be as generic as possible and finer grained concurrency should be explicitly handled by the user, but as Mr. Rachum said, a shortcut between the finest granularity (user have to submit futures manually) and generic serial-like map could be of use (It would help write DRY code since this is a really common use case).</div>

<div><br></div><div>I am not necessarily for the creation of a new function implicitly doing an unordered iteration, though. Since futures.map returns an iterator, I think we should provide users with a function that wraps the futures.map and allow users to explicitly call it for unordered iteration. This could be very intuitive -- Like allowing futures.as_completed to accept futures.map() output. This could be done using the object-oriented philosophy (by keeping some internal state linking the map result to their related future) or functional philosophy (by returning an object behaving like the result with the addition of an identifier to the future). Internally, the function could either implement a callback returning the value to the user as soon as results are available or call as_completed on their related futures.</div>

<div><br></div><div>Either way (new function or new wrapper) would greatly simplify some usual use cases of concurrent or parallel programs using or inspired by PEP-3148.</div><div><br></div><div>Have a nice day,</div><div>

Yannick Hold</div></div></div></div>
</div><br></div>