Iterator / Iteratable confusion
Terry Reedy
tjreedy at udel.edu
Tue Feb 15 19:25:30 EST 2005
"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
More information about the Python-list
mailing list