[Python-ideas] Cofunctions PEP - Revision 4
greg.ewing at canterbury.ac.nz
Tue Aug 17 02:16:32 CEST 2010
M.-A. Lemburg wrote:
> If you could turn your proposal into something more like
> the Stackless tasklets and move the implementation to an
> extension module (perhaps with some extra help from new CPython
> APIs), then I'm sure the proposal would get more followers.
As far as I can see, it's impossible to do what I'm
proposing with standard C and without language support.
That's why greenlets have to resort to black magic.
> "explicit is better than implicit".
This is a strange argument to be making in favour of
Stackless, though, where the fact that you're dealing
with suspendable code is almost completely *implicit*.
> Tasklets are normal Python objects wrapping functions.
> The create of those tasklets is explicit, not implicit
> via some (special) yield burried deep in the code.
So would you be more in favour of the alternative version,
where there is 'codef' but no 'cocall'?
> I think an important part of the criticism is
> hiding the fact that you are writing a cofunction
> away inside the function definition itself.
The only reason I did that is because Guido turned his
nose up at the idea of defining a function using anything
other than 'def'. I'm starting to wish I'd stuck to my
guns a bit longer in the hope of changing his sense of
> Well, viruses will have a harder time for sure ;-) I am not
> aware of other use cases that would need to know the
> location of the stack frame in memory.
One way it can happen is that a task sets up a callback
referencing something in a stack frame, and then the
callback gets invoked while the task is switched out,
so the referenced data isn't in the right place. I
believe this is the kind of thing that was causing the
trouble with Tkinter.
More information about the Python-ideas