Hello,
Greg Ewing:
M.-A. Lemburg wrote:
Sure, and those use Stackless to solve the problem, which IMHO provides a much more Pythonic approach to these things.
At the expense of using a non-standard Python installation, though. I'm trying to design something that can be incorporated into standard Python and work without requiring any deep black magic. Guido has so far rejected any idea of merging Stackless into CPython.
Note, that there is also greenlet library that provides such part of functionality from Stackless (except preemptive scheduling and pickling) and eventlet/gevent libraries that is quite popular solutions for network applications written in Python, which use greenlet.
And I'm not sure what criteria to judge pythonicity by in all this. Stackless tasklets work without requiring any kind of function or call markers -- everything looks exactly like normal Python code. But Guido and others seem to be objecting to my implicit-cocall proposal on the basis that it looks *too much* like normal code. It seems to me that the same criticism should apply even more to Stackless.
For me the fact that greenlet code looks like normal code is more preferable against generator-based coroutines (I think they are overuse of generator syntax). Also I don't see the need to explicit cocall:
1) It will increase the complexity of language without necessity — we have no special syntax for threading, so why we should have one for cooperative threads? Semantics are almost the same relative to unthreaded Python, except with cooperative threading we should explicitly control execution, which has less semantic impact than preemptive threading code, I think.
2) That will affect code reusability a lot, because we can't mix cocalls and calls.
All this issues are solved with greenlet library and I think if Python needs cooperative threads they should have API and behave like greenlets.