Iterator / Iteratable confusion

[Terry Reedy]

"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'.

Terry J. Reedy