[Python-Dev] Single- vs. Multi-pass iterability

[Oren Tirosh]

On Fri, Jul 12, 2002 at 08:27:56AM -0400, Andrew Koenig wrote:
> Oren> There is no need for a new type of iterator. It's ok that
> Oren> iterators are disposable.  If I need multiple iterations I don't
> Oren> want to copy the iterator - I prefer to ask the original
> Oren> iterable object for a new iterator.  All I need is some way to
> Oren> know whether the iterable object (container) can produce
> Oren> multiple iterators that generate the same sequence.
> 
> You are assuming that you still have access to the original iterable
> object.  But what if all you have is an iterator?  Then you need to
> be able to ask the iterator for a new iterator.

Here are two cases I can think of where I don't have access to the iterable
object:

1. There is no iterable object. An iterator object was created directly.
For example, the result of a generator function is an iterator which isn't
the result of some container's __iter__ method.

2. The iterator was received as an argument and the caller sent iter(x) 
instead of x.  In that case I guess it means that the caller doesn't *want* 
to give me access to x.  

> Oren>   An object is re-iterable if its iterators do not modify its state.
> 
> Oren> The iterator of an iterator is itself.  Calling the next method,
> Oren> by definition, modifies the internal state of an
> Oren> object. Therefore anything that has a next method is not
> Oren> re-iterable.
> 
> That's not the only possible definition of an iterator.

It isn't a definition of an iterator.  It isn't even a definition of a 
re-iterable object, it's a sufficient (but not required) condition for 
objects to be re-iterable.

> I'm thinking, in part, about how one might translate some of the C++
> standard-library algorithms into Python.  

Why not translate *what* they do instead of *how* they do it? I'm pretty
sure the Python way would be shorter and simpler anyway.

	Oren