Feature/use python future

[darkjh]

For issue #9

It's easier than I thought. Comment please.

[ggreg]

self._condition is specific to Python concurrent.futures implementation.

[darkjh]

Yes but as we reuse concurrent.futures.Future, the usage of this conditional lock should be consistent, right?

[ggreg]

I assume that concurrent.futures.Future was not intended to be a base class as the module lacks an abstract base class. Hence it already comes with some implementation details like the threading.Condition used to wait until the completion of the task.

I suggest we add this missing abstract base class that comes with the _condition attribute.

[darkjh]

or we just don't care about the _condition here in SwfFuture, they are not useful.

[ggreg]

⚠️ Beware switching back from class properties to methods changes the interface of Future and breaks compatibility.

[ggreg]

Let's add an abstract base class simpleflow.futures.AbstractFuture.

And then inherit from it inside the packages that provides the backend implementations such as:

• Local synchronous and asynchronous future in simpleflow.local.futures: class Future(concurrent.futures, simpleflow.futures.AbstractFuture)
• SWF in simpleflow.futures: class Future(simpleflow.futures.AbstractFuture)

In local, the multiple inheritance is required to enforce custom feature of simpleflow added to the genuine concurrent.futures.Future.

[darkjh]

@ggreg updated like what we've discussed last friday.
It seems that we've an swf authentication error during Travis build.

[ggreg]

@darkjh #6 will allow to run the tests on Travis without calling the SWF API.

[ggreg]

Thanks for the update, I have not reviewed it yet.

[ggreg]

👍

Thanks @darkjh! Simpleflow 0.2.3 is in testing. When it will be validated, I'll merge #17. You can then rebase this pull request and we will merge it.

[ggreg]

It will allow to continue the work on #8.

[darkjh]

Yay! Rebase et tests passed!

[ggreg]

Great! Kudos @darkjh.

[darkjh]

@ggreg it's the right time to merge this?

[darkjh]

@ggreg it seems now the default branch is master? Also I didn't understand the test fail under pypy ...

[darkjh]

@ggreg all tests pass under pypy-2.4.0 on my machine.

[ggreg]

Travis uses pypy 2.5.0. I need to make the test fail with pypy locally.

[darkjh]

I found that the 'dummy' future is very difficult to handle in this case.
With this PR, we'll have different Future for different executor backend. So explicitly instantiate an Future in the workflow definition is problematic: in the executor agnostic workflow definition, we need to know which Future to instanciate ..
Let me know what you think on this @ggreg