[Python-ideas] Cofunctions - Back to Basics
Paul Moore
p.f.moore at gmail.com
Sat Oct 29 12:51:55 CEST 2011
On 29 October 2011 11:22, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I think eventually the PEP should move towards a more explanatory model:
> - "coroutines are a tool for lightweight cooperative multitasking"
> - "coroutines are cool for a variety of reasons (aka people didn't
> create Twisted, Stackless, greenlets and gevent just for fun)"
> - "here's how this PEP proposes this functionality should look (aka
> Lua's coroutines look pretty nice)"
> - "rather than saving and switching entire stack frames as a unit,
> Python's generator model supports coroutines by requiring that every
> frame on the stack know how to suspend itself for later resumption"
> - "doing this explicitly can be quite clumsy, so this PEP proposes a
> new protocol for invoking arbitrary functions in a way that sets them
> up for cooperative multitasking rather than assuming they will run to
> completion immediately"
> - "this approach allows C extensions to play nicely with coroutines
> (by implementing __cocall__ appropriately), but doesn't require low
> level assembly code the way Stackless/greenlets do"
That looks reasonable. There's one further piece of the puzzle I'd
like to see covered, though - with the language support as defined in
the PEP, can the functionality be implemented library-style (like Lua)
or does it need new syntax? The PEP should discuss this, and if syntax
is needed, should propose the appropriate syntax.
I think that if the runtime support can be built in a way that allows
a Lua-style function/method approach, then that should be the initial
design, as it's easier to tweak a functional API than to change
syntax. If experience shows that code would benefit from syntax
support, add that later.
Paul.
More information about the Python-ideas
mailing list