Guido van Rossum added the comment: 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). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20566> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
