M.-A. Lemburg wrote:
Greg Ewing wrote:
In an application that requires thousands of small, cooperating processes,
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.
Also I gather that Stackless works by copying pieces of C stack around, which is probably more lightweight than using an OS thread, but not as light as it could be.
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.
The techniques used by Stackless to achieve this are nasty, but then Python also ships with ctypes which relies on similar nasty techniques
But at least it works provided you write your ctypes code correctly and the library you're calling isn't buggy. I seem to remember that there are certain C libraries that break Stackless because they assume that their C stack frames don't move around.