[Python-ideas] PEP draft - Composable futures for reactive programming

[Andrew Barnert]

A few things I'd like to see.

Your Future uses a condition variable. That could be a big hit for single threaded uses, and since one of your goals is to make asyncio use the same futures as threaded executors, that might not be acceptable. How hard would it be to allow passing a class (or other factory callable) in place of the default condition when constructing a Promise, or just a "threaded=True" flag. (I realize this is more complicated than it sounds--an event loop can always push callbacks onto a thread pool, or just use a thread pool to implement something that's hard to do in a single thread, like DNS lookup--so you probably also need a way to upgrade a single threaded promise to a thread safe one.)

There's a lot of rationale about why separate futures and promises are important, but no rationale for the specific design. If you explained where you deviated from twisted Deferred, JS Promises/A, etc., and why, it would be a lot easier to evaluate your design.

It's not documented how chaining multiple callbacks in sequence works. Does the second callback get the return value of the first one, or the original one? Can you return a new future (possibly with callbacks already attached, possibly already completed)?

Sent from a random iPhone

On Dec 21, 2013, at 5:14, Sergii Mikhtoniuk <mikhtonyuk at gmail.com> wrote:

> Hi all,
> 
> I would very much appreciate your opinion on my proposal for improvement of concurrent.futures package.
> 
> Comparing to other languages such as Scala and C#, Python’s futures significantly fall behind in functionality especially in ability to chain computations and compose different futures without blocking and waiting for result. New packages continue to emerge (asyncio) which provide their own futures implementation, making composition even more difficult.
> 
> Proposed improvement implements Scala-like Future as a monadic construct. It allows performing multiple kinds of operations on Future’s result without blocking, enabling reactive programming in Python. It implements common pattern separating Future and Promise interface, making it very easy for 3rd party systems to use futures in their API.
> 
> Please have a look at this PEP draft, and reference implementation (as separate library).
> 
> I’m very interested in:
> - How PEPable is this?
> - What are your thoughts on backward compatibility (current implementation does not sacrifice any design points for it, but better compatibility can be achieved)?
> - Thoughts on Future-based APIs in other packages?
> 
> Thanks,
> Sergii
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131221/dfab5294/attachment.html>