[Python-Dev] [PEP 3148] futures - execute computations asynchronously

[Jesse Noller]

On Sat, Mar 6, 2010 at 9:34 PM,  <exarkun at twistedmatrix.com> wrote:
> On 02:10 am, brian at sweetapp.com wrote:
>>
>> On 7 Mar 2010, at 03:04, Phillip J. Eby wrote:
>>>
>>> At 05:32 AM 3/6/2010, Brian Quinlan wrote:
>>>>
>>>> Using twisted (or any other asynchronous I/O framework) forces you to
>>>> rewrite your I/O code. Futures do not.
>>>
>>> Twisted's "Deferred" API has nothing to do with I/O.
>>
>> I see, you just mean the API and not the underlying model.
>>
>> We discussed the Deferred API on the stdlib-sig and I don't think that
>> anyone expressed a preference for it over the one described in the PEP.
>>
>> Do you have any concrete criticism?
>
> From reading some of the stdlib-sig archives, it sounds like there is
> general agreement that Deferreds and Futures can be used to complement each
> other, and that getting code that is primarily Deferred-based to integrate
> with Future-based code or vice versa should eventually be possible.
>
> Do I have the right sense of people's feelings?
>
> And relatedly, once Futures are accepted and implemented, are people going
> to use them as an argument to exclude Deferreds from the stdlib (or be
> swayed by other people making such arguments)?  Hopefully not, given what I
> read on stdlib-sig, but it doesn't hurt to check...
>
> Jean-Paul

Generally speaking; I don't see futures as an exclusion to Deferreds,
or other asynchronous doodads. I just see it as a useful construct on
top of threads and processes primarily. So in my mind, no.

jesse