Enhanced Generators - the difference between sources and iterators

[Oren Tirosh]

On Thu, Jan 31, 2002 at 02:53:15AM -0500, Raymond Hettinger wrote:
> At the suggestion of  Kragen Sitaker, the arguments for xmap(), xzip(), and
> indexed() are now called collections rather than sequences.

I prefer the term source. 

iterable: 
   anything for which iter() is valid.

iterator: 
    an iterator is a temporary object that may be iterated once
    x is an iterator if iter(x) is x

source: 
    A source is a persistent object that may be iterated multiple times.
    Python containers are sources.  Returns a fresh, independent iterator 
    for each iter() call

generator: 
    An iterator created by calling a generator function.  

generator function:
    A magic function returning a generator.  A generator function is NOT
    a source because it does not have an __iter__ method.  However,
    a generator function with no arguments is a convenient way to implement
    an source's __iter__ method.

My implementation of xmap, xfilter and xzip returns a source, not an
iterator.  It can be iterated multiple times, just like the output of map,
filter or zip.

The logical opposite of a source is a destination.  Destinations should
be able to produce a temporary object mirroring an iterator.  I call such 
an object a sink (PLUG: see http://tothink.com/python/dataflow)

> Addressed Alex Martelli's question about why .submit() was used instead of
> overloading .next()

Why invent a new protocol when on already exists in the Python library? the
HTMLparser object has the method .feed() to implement pushing data to a
sink.


I'm not sure what you expect two-way generators to be used for.  If the two
directions of communications are used as the upstream and downstream
directions of a filter in stream they should be independent, not using the 
same generator object.  Are they meant for bidirectional communication 
between two entities?  Dialogues are rather rare as a form of interconnection 
between parts of the same program.  Dialogues are common in communication 
but I don't believe that was your intention.

I'm in favor of one-way consumer functions to mirror generator functions,
but not two-way generators.  

	Oren