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.

Author gvanrossum
Recipients glangford, gvanrossum, pitrou, vstinner, yselivanov
Date 2014-02-09.01:17:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1391908643.29.0.569488321764.issue20566@psf.upfronthosting.co.za>
In-reply-to
Content
I'm looking into a solution for this. The idea is pretty straightforward: http://codereview.appspot.com/61210043.

This needs more code to support the optional timeout feature, and it now returns Futures instead of coroutines (which I think is fine).

But to my surprise, test_as_completed_reverse_wait() failed. After nearly an hour of debugging my own code I realized that this test specifically verifies the following weird behavior: if you get two values (futures/coroutines) out of as_completed() without waiting for either, and then wait for the *second* one, it will wait for the *first* result. I guess this is defensible because it is the first one you wait for, but I find it hard to believe that this is desirable behavior -- even though I wrote the code and the test! (http://code.google.com/p/tulip/source/detail?r=674355412f33.)

So I'd like permission to just change these semantics. They aren't clear from the docs or from PEP 3156, and concurrent.futures.as_completed() doesn't have the same issue (there, __next__() on the iterator blocks until the result is ready).
History
Date User Action Args
2014-02-09 01:17:24gvanrossumsetrecipients: + gvanrossum, pitrou, vstinner, yselivanov, glangford
2014-02-09 01:17:23gvanrossumsetmessageid: <1391908643.29.0.569488321764.issue20566@psf.upfronthosting.co.za>
2014-02-09 01:17:23gvanrossumlinkissue20566 messages
2014-02-09 01:17:19gvanrossumcreate