On Sat, Aug 7, 2010 at 5:20 PM, Nick Coghlan firstname.lastname@example.org wrote:
On Sun, Aug 8, 2010 at 12:51 AM, Guido van Rossum email@example.com wrote:
On Sat, Aug 7, 2010 at 3:05 AM, Carl M. Johnson firstname.lastname@example.org wrote:
Of course, as we all know on the OS side of things, cooperative multitasking has been more or less phased out [...]
I don't think you can see this as reflecting badly on cooperative multitasking. Rather, it is now understood better and has moved entirely to user space, leaving the OS to deal with preemptive threads, which cannot work well without OS support. As an example of cooperative multitasking being alive and well, see Stackless, Greenlets, and, in fact, coroutines built out of generators (possible in Python 2.5 and later).
Even simpler: GUI event loops are fundamentally about cooperative multi-tasking. To me, the cofunction idea is really about making it easier to write event loop code.
I actually added a reference to Twisted to my email, and then took it out because (while I agree to a point) the programming model with callbacks is so different that the word "task" doesn't really cover it for me. But it is indeed all about total app control over where to suspend execution in favor of another activity.
I think PEP 380 works well on its own, but will work better when paired with a separate cofunctions PEP
We'll see. I still cannot get my head around why cofunctions are so great. (Also the name sucks for me.)
(similar to how PEP 342 and PEP 343 were best considered as a pair of co-proposals that went together, even though they were technically independent of each other).
That's a rather one-sided relationship though. While PEP 343 deeply relies on the improvements to yield (especially close() and the new exception semantics), the main subject of PEP 342 (coroutines) couldn't care less about with-statements (unless there's a pattern I'm missing).