[Python-ideas] Cofunctions PEP - Revision 4
mal at egenix.com
Fri Aug 13 13:02:56 CEST 2010
Greg Ewing wrote:
> On 12/08/10 18:44, ghazel at gmail.com wrote:
>> why not just use threads?
> One reason not to use threads is that they're fairly heavyweight.
> They use OS resources, and each one needs its own C stack that
> has to be big enough for everything it might want to do. Switching
> between threads can be slow, too.
> In an application that requires thousands of small, cooperating
> processes, threads are not a good solution. And applications
> like that do exist -- discrete-event simulation is one example.
Sure, and those use Stackless to solve the problem, which IMHO
provides a much more Pythonic approach to these things.
Stackless also works across C function calls, a detail which will become
more important as we think about JIT compilers for Python and
which is not something we want the average Python programmer
to have to worry about. Stackless hides all these details from
the Python programmer and works well on the platforms that it
So if we really want such functionality in general Python (which
I'm not convinced of, but that may be just me), then I'd
suggest to look at an existing and proven approach first.
The techniques used by Stackless to achieve this are nasty, but then
Python also ships with ctypes which relies on similar nasty techniques
(hidden away in libffi), so I guess the barrier for entry
is lower nowadays than it was a few years ago.
Professional Python Services directly from the Source (#1, Aug 13 2010)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
More information about the Python-ideas