[Python-Dev] Single- vs. Multi-pass iterability
Fri, 12 Jul 2002 16:04:18 +0300
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
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.