Enhanced Generators - two-way generators

[Oren Tirosh]

On Fri, Feb 01, 2002 at 03:04:31PM -0500, Raymond Hettinger wrote:
> > I'm in favor of one-way consumer functions to mirror generator functions,
> > but not two-way generators.
> 
> Why deny yourself the ability to pass data along with control flow.  I don't
> really change anything, control flow stays the same.  The proposal just
> gives a way to pass some data along the way.  If you HAVE TO send some
> data in, the existing alternative using global variables truly sucks
> (error prone, hard to read, unclear in its intention).  If you don't HAVE
> TO, then you've lost nothing as the argument to .next() and yield assignment
> are optional.

Try to think about how to describe this object in a few short sentences
and the problems become more apparent.  
  
Here's a description for the usage of iterators and generators:

   "An iterator has a next() method returning the next item; raises 
    StopIteration if no more data is available."

   "Calling a generator function returns a generator object implementing
    the iterator protocol."

Here's a description for the usage of sinks and consumers:

   "A sink has a submit() method to which one argument is passed; this 
    object is sent to the sink's destination for processing.".

   "Calling a consumer function returns a consumer object implementing
    the sink protocol."

Both of these descriptions are complete, self-contained descriptions of a
stream of objects.  It is easy to convert one to the other, connect streams
together, perform arbitrary transformations on streams, etc.

And a description for the usage of your extended iterators and generators:

   "An extended iterator has a next() method that may or may not take an
    argument. The return value of the next() method may or may not contain 
    relevant data."
 
   "Calling a generator function returns an object implementing the extended
    iterator protocol. This object may either generate data, consume data 
    or implement some two-way dialogue."

Yes, there is such a thing as too much flexibility.  This protocol is not
self-contained and requires additional agreements just to get the data
across.  

This year is the 30th anniversary of Unix pipes, invented by Doug McIlroy.  
I think this is enough experience to build on.  In practice, pipe 
programming is used for pipelines of processing stages, not for dialogue. 
Dialogues are used for terminals with human operators, but are very rare as
a building block inside a program.  They are mostly used when a tool 
designed for human interaction is used in an automated manner, not as a
first choice.

	Oren