将Python期货用于没有结果的任务是一个好主意吗？

Question

The question came up, when I started implementing asynchronous set and get operations on an object using the concurrent.futures module like this:

import time
from concurrent.futures import ThreadPoolExecutor

executor = ThreadPoolExecutor(max_workers=2)

class Foo(object):
    def set_something(self):
        def long_running_setter():
            time.sleep(1.5)
            print('Set something')
        return executor.submit(long_running_setter)

    def get_something(self):
        def long_running_getter():
            time.sleep(0.5)
            return 'something'
        return executor.submit(long_running_getter)

foo = Foo()
future = foo.get_something()
print("Got " + future.result())

But now, setting a value and waiting for it becomes a little bit awkward to use and semantically "incorrect"

foo.set_something().result()

although I feel it's still valid, because the Foo object is at the lowest level and further abstractions could be built on top of the futures.

So, to sum up my problem:

• Are futures the right kind of abstractions to get/set values asynchronously from an object? Especially for setters which do not return any value?
• Should I add a blocking parameter to set_something in order to get rid of the result() call? I have my doubts with this approach, because then I'd encourage not to use futures at all.
• How would you do it?

Answer 1

If the action must be completed before you can continue past a certain point in the code, you need some way to block/join/wait.

Python properties are much preferred to Java-style getters and setters (like obj.get_x and obj.set_x ). Because properties masquerade as regular attributes, it'd be bad style to have asynchronous code triggered by a property.

Many people find that object-orientation gets them into trouble with asynchronous code and they prefer to use a more functional style. Luckily, Python supports using either programming paradigm.