Iterator / Iteratable confusion

[Adam DePrince]

On Tue, 2005-02-15 at 19:25, Terry Reedy wrote:
> "Michael Spencer" <mahs at telcopartners.com> wrote in message 
> news:cuthdk$dnq$1 at sea.gmane.org...
> 
> > Terry, thanks for responding in depth.
> We are both interested in the murky edges at and beyond conventional usage.
> > Terry wrote
> >> 2. "It is not essential to not do something wasteful as long as it is >> 
> >> otherwise inconsequential."
> > Not that "iter(iterator) is iterator" is somehow wasteful (actually it > 
> > seems  conservative), but rather that alternative behavior is readily 
> > implmented.
> What I was pointing to as wasteful is the application of your alternative 
> behavior where an object is replaced by a copy and then effectively tossed.
> > However, I suggest that there may be cases where
> > "iter(iterator) is not iterator" is useful behavior.
> I am quite aware that multiple iterators for the same iterable (actual or 
> conceptual) can be useful (cross products, for example).  But I am dubious 
> that initialized clones of 'iterators' are *more* useful, especially for 
> Python, than multiple iterators derived from repeated calling of the 
> callable that produced the first iterator.  It might be different if Python 
> were a prototype/clone language rather than a typeclass/instance language. 
> It is also possible that we have slightly different ideas of 'useful' in 
> the Python context.
> In your example, as I pointed out, A.__iter__ and AnIterator.__iter__ have 
> the same code, so I could not see any advantage to getting a copy through 
> calling the latter instead of the former.  For the disadvantage, see below.
> >  What to call such an object is another matter.
> spencerator ;-?
> Here are some related reasons why I think it useful if not essential to 
> restrict the notion of iterator by restricting  iterator.__iter__ to 
> returning self unmodified.
> Leaving Python aside, one can think of iterable as something that 
> represents a collection and that can produce an iterator that produces the 
> items of the collection one at a time.  In this general conceptioning, 
> iterables and iterators seem distinct (if one ignores self-iterables).  In 
> Python, giving iterators an __iter__ method, while quite useful, erases 
> (confuses) the (seeming) distinction, but giving them a minimal __iter__ 
> does so minimally, keeping iterators a distinct subcategory of iterable. 
> Spencerators confuse the distinction more than minimally and define a 
> vaguer subcategory.
> Essential?  For something defined as minimal, it is essential that it be 
> minimal.  But you point seems to be that it is not essential that iterator 
> be so defined.  Ok.
> (Aside: an iterator can be thought of as representing the sequence of 
> future .next() returns.  From this viewpoint, making iterators a 
> subcategory of iterable is more than just a convenience.)
> Taking Python as it is, a useful subcategory of iterable is 'reiterable'. 
> This is distinct from iterator strictly defined.  This we have iterables 
> divided into iterators, reiterables, and other.  I think this is 
> didactically useful.  Spencerators are reiterables.
> Iter(iterator) returning iterator unchanged makes iterator a fixed point of 
> iter.  It ends any chain of objects returned by repeated iter calls. 
> Spencerators prolong any iter chain, making it infinite instead of finite. 
> Essential?  Repeat the paragraph above with 'a fixed point' substituted for 
> 'minimal'.

How is spencerator different than itertools.tee?


Adam DePrince