On Tue, 2005-02-15 at 19:25, Terry Reedy wrote: > "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'.
How is spencerator different than itertools.tee? Adam DePrince -- http://mail.python.org/mailman/listinfo/python-list
