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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4