On Sat, Mar 6, 2010 at 9:34 PM, <exar...@twistedmatrix.com> wrote: > On 02:10 am, br...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
