PEP 255: Simple Generators

[Roman Suzi]

On Thu, 21 Jun 2001, Glyph Lefkowitz wrote:
 
> My $0.02 on the whole issue:
> 
> Generators a-la PEP 255 seem like a *very* bad idea to me.
> 
> Generators can be implemented through continuations (as shown in
> Stackless) or through microthreads (as shown in the various previous
> implementations of generators which use *real* threads cooperatively).
> 
> Neither microthreads nor continuations are implementable through
> generators.  I believe that generators (as described in PEP 255) are a
> merely a convenience, but real cooperative multithreading could be very
> useful and we would get generators *for free*.
> 
> While I am heavily in support of stackless being integrated for many
> reasons, I can understand the unfavorable sentiments that some harbor
> towards continuations.  They can be nastily abused.  They are
> confusing.  They interact very poorly with operator overloading and
> exception handling.
> 
> However, yeild adds a way of altering control flow without providing a
> direct mechanism for accessing that alteration; only using one particular
> feature of that alteration.  One real example -- the reason I'm writing
> this reponse -- I have written an asynchronous networking library.  
> Currently, the API is that the client "protocol" code handles each chunk
> of data, maintaining a buffer itself, and then handling an event when a
> full message chunk of data is received.  Certain protocols would be much
> easier to code with a synchronous view of handling data; indeed, this is
> the way that most protocol code in Python itself is written.  If the
> protocol code is executing a read(), however, I want control flow to
> return to my main asynchronous control loop while that code is
> blocked.  There are, unfortunately, many places executing read() and only
> one execution path which knows which one it wishes to yield *to*.
> 
> I believe that this is a fairly common application.
> 
> The motivation for implementing PEP 255 is exactly this -- a situation
> where execution should proceed asynchronously but the application should
> be written synchronously for clarity.  The general solution to this
> problem is cooperative multithreading.
> 
> Benefits to this approach would be: 
> 
>  * one-to-many relationships (as described above) are handled as well as
>    many-to-one.
>  * more pythonic: implement a general approach in the core and build upon
>    it rather than a specific approach in the core.
> 
> Disadvantages to the PEP 255 approach:
> 
>  * we'll probably want microthreads eventually; this feature will bloat
>    the language unnecessarily then.
>  * less pythonic: once we've implemented generators this way, what about
>    simulation loops?  Do we need syntax support for those too?
> 
> The one advantage to the PEP 255 way of doing things is that it looks like
> it might be slightly easier to implement.  However, C. Tismer has already
> shown it's not insurmountable to implement microthreads in Python, and
> perhaps some, if not all, of his work could be stolen ;-).

This is almost exactly what I was trying to tell c.l.p for two days.
Let's call it microthreads, but it is correctly put!

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -