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

[Guido van Rossum]

I'm pretty worried about this proposal. It seems to encourage
callback-style programming, whereas I would like to get away from it
(that's the main thrust of asyncio/PEP 3156). The proposal reminds me
of Twisted Deferred, which is too complicated for my taste.

Note that asyncio has a composition operation of its own, gather(),
but encourages using standard try/except/else/finally syntax for error
handling, rather than adding Twisted-style errbacks.

Nevertheless it is possible that I am misunderstanding the proposal
(e.g. the distinction between Future and Promise wasn't clear from
reading the draft PEP, nor how it would interact with asyncio). I
recommend that the author work find a way to improve the English
grammar of the proposal, e.g. by working with a native speaker.

On Sat, Dec 21, 2013 at 6:12 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 21 December 2013 23:14, Sergii Mikhtoniuk <mikhtonyuk at gmail.com> wrote:
>> Please have a look at this PEP draft, and reference implementation (as
>> separate library).
>>
>> I’m very interested in:
>> - How PEPable is this?
>
> This looks like a really interesting idea, and well worth pursuing as
> a PEP for 3.5 (the failure to make the Future/Promise split was
> actually noted as a flaw in the concurrent.futures design at the time,
> but wasn't seen as serious enough to prevent inclusion of the module.
> However, this draft PEP does a decent job of showing the kinds of
> operations that the current combined class design can make difficult)
>
>> - What are your thoughts on backward compatibility (current implementation
>> does not sacrifice any design points for it, but better compatibility can be
>> achieved)?
>
> Yes, I think better compatibility is needed. One possible option would
> be to take the path of defining a "concurrent.futures.abc" module that
> provides this higher level API, and largely leave the existing
> concrete classes alone (aside from adjusting them to fit the ABC).
>
> The main possible issue I see is with the result setting APIs on the
> existing Future objects.
>
> There are also a lot of staticmethod declarations that look like they
> should probably be classmethod declarations.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> 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/



-- 
--Guido van Rossum (python.org/~guido)