[stdlib-sig] futures - a new package for asynchronous execution
Brian Quinlan
brian at sweetapp.com
Sat Nov 7 06:11:27 CET 2009
On Nov 7, 2009, at 11:44 AM, Jesse Noller wrote:
> On Fri, Nov 6, 2009 at 5:35 PM, Brian Quinlan <brian at sweetapp.com>
> wrote:
>> Hey all,
>>
>> I'd like to propose adding a module/package to Python that makes it
>> easy to
>> parallelize arbitrary function calls.
>> I recently wrote a solution for the use case of parallelizing
>> network copies
>> and RPC using threads without forcing the user to explicitly
>> creating thread
>> pools, work queues, etc.
>> I have a concrete implementation that I'll describe below but I'd
>> be happy
>> to hear about other strategies!
>> The basic idea is to implement an asynchronous execution method
>> patterned
>> heavily on java.util.concurrent (but less lame because Python has
>> functions
>> as first-class objects). Here is a fairly advanced example:
>> import futures
>> import functools
>> import urllib.request
>>
>> URLS = [
>> 'http://www.foxnews.com/',
>> 'http://www.cnn.com/',
>> 'http://europe.wsj.com/',
>> 'http://www.bbc.co.uk/',
>> 'http://some-made-up-domain.com/']
>>
>> def load_url(url, timeout):
>> return urllib.request.urlopen(url, timeout=timeout).read()
>>
>> # Use a thread pool with 5 threads to download the URLs. Using a pool
>> # of processes would involve changing the initialization to:
>> # with futures.ProcessPoolExecutor(max_processes=5) as executor
>> with futures.ThreadPoolExecutor(max_threads=5) as executor:
>> future_list = executor.run_to_futures(
>> [functools.partial(load_url, url, 30) for url in URLS])
>>
>> # Check the results of each future.
>> for url, future in zip(URLS, future_list):
>> if future.exception() is not None:
>> print('%r generated an exception: %s' % (url,
>> future.exception()))
>> else:
>> print('%r page is %d bytes' % (url, len(future.result())))
>>
>> In this example, executor.run_to_futures() returns only when every
>> url has
>> been retrieved but it is possible to return immediately, on the first
>> completion or on the first failure depending on the desired work
>> pattern.
>>
>> The complete docs are here:
>> http://sweetapp.com/futures/
>>
>> A draft PEP is here:
>> http://code.google.com/p/pythonfutures/source/browse/trunk/PEP.txt
>>
>> And the code is here:
>> http://pypi.python.org/pypi/futures3/
>>
>> All feedback appreciated!
>>
>> Cheers,
>> Brian
>> _______________________________________________
>> stdlib-sig mailing list
>> stdlib-sig at python.org
>> http://mail.python.org/mailman/listinfo/stdlib-sig
>>
>>
>
> Hey brian; a few things - I think the code looks good, and your docs
> are really good so far;
Cool, thanks.
> but I'd personally like to see tests
The tests live here:
http://code.google.com/p/pythonfutures/source/browse/trunk/python3/test_futures.py
Last time I measured, there was 100% test coverage (it's a crappy
metric but an easy one) but I'm not completely happy with them because
they use time.sleep() in several places to try to provoke deadlock.
> and more
> examples within the docs. I obviously like the concept/idea, but tests
> are a must, and more examples in the docs would make it a lot better.
More examples in the docs sound good, I'll work on that.
Cheers,
Brian
More information about the stdlib-sig
mailing list