Python concurrent.futures as_completed: Handle Results as They Finish

Select a timestamp to watch that moment on YouTube.

1. 00:00

   Use concurrent.futures.as_completed(futures) when you want to react as submitted tasks finish rather than wait for their original input order. submit returns Future objects; each Future stores a result or exception. as_completed yields futures, not plain values, so call future.result() inside the loop. Map each future back to its input if the output needs a label. A Future holds the eventual result or exception of a task. as_completed accepts an iterable of Future objects and yields each after it completes. In this browser example both Futures are already finished, so no operating-system thread is started.

2. 00:41

   Sort the numeric results because the order among already completed Futures is not the contract we want to test. A Future is a handle for work that has been submitted, not the result itself. Storing the handle lets us ask whether the work is done, cancel it if the state permits, or call result when it completes. The as_completed iterator does not change the worker jobs; it changes the order in which the caller learns about them. We can therefore display or store a fast result while a slower sibling is still running. A common mistake is iterating over the original future list and calling result() in that order. If the first job is slow, the loop waits there even when later jobs have finished.

3. 01:25

   The video uses controlled local ThreadPoolExecutor jobs to make the difference visible. Actual completion order depends on timing and must not be treated as deterministic application data. For live local work, submit functions to a ThreadPoolExecutor, store the returned Futures, then loop over as_completed. This lets the caller react to a fast job while a slower job is still running. Do not claim that every use of threads makes Python computation faster; the use case here is overlapping waits and handling arrival of results. A Future alone does not explain which input was submitted. Keep a mapping from Future to label when calling submit.

4. 02:08

   In the browser example the mapping is constructed manually, then the result dictionary is compared with the expected labels and values. Dictionary equality ignores insertion order, which matters because completion order can vary. future.result() reraises the exception from that job. Catch a specific exception around each result so one bad item can be reported without hiding successful work. If a job fails, choose whether to continue, cancel others, or fail the whole batch; the appropriate policy depends on the program. as_completed's timeout applies to the iterator and raises TimeoutError when a next completion does not arrive in time.

5. 02:51

   If the application needs to display results as they arrive, it can print or send each pair immediately. If it needs input order later, store values by label or original index and reorder for presentation. as_completed is about when the caller can handle each completion, not about promising a particular order in the final report. The browser exercise operates on already completed Future objects so it can test result collection without starting operating-system threads. The recorded local example uses ThreadPoolExecutor for real overlapping work. Neither one promises a speedup for CPU- bound Python code under the usual GIL.

6. 03:34

   Compare this API with the site's asyncio lessons: they solve related coordination problems but have different scheduling and cancellation models. A worker exception does not necessarily interrupt submit. It is retained by the Future and reraised when result() is called. The third example sets a ValueError explicitly so that the error path is reproducible without a thread. Catch the known exception around one result, then decide whether to record a marker or stop the batch. The checked task records '<error>' for ValueError and continues collecting other jobs. That is an exercise policy, not a universal recommendation: some programs

7. 04:15

   must fail the whole operation instead. Also consider timeouts and cancellation in a real executor. A timeout on as_completed raises when the next completion cannot be obtained within its bound. Rewrite collect_finished(jobs) to loop over as_completed(jobs), call future.result(), and map each completed Future to its label. Return a dictionary of successful results. If a Future raises ValueError, record '<error>' for that label and continue. The browser exercise uses completed futures; run the threaded demonstration locally. The local run deliberately uses different sleep durations so the order is visible,

8. 04:58

   but production code should never depend on which thread wins a timing race. Tests for the collected values should compare by label or use a set when order is irrelevant. If presentation requires original input order, save each result under its input index and sort afterward. Completion order and display order are separate decisions. At PythonLessonLab, work through the matching lesson and run the checked task. Explain the output before changing the code, then make one small change and rerun the boundary case. The result matters more than memorizing a function name: you should know what it accepts, what it returns, and which failure it prevents.