"Michael Spencer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> 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 -- http://mail.python.org/mailman/listinfo/python-list
