[Python-ideas] Introduce collections.Reiterable

Stephen J. Turnbull stephen at xemacs.org
Fri Sep 20 18:53:02 CEST 2013

Neil Girdhar writes:

 > Many different solutions would fix the problems I've seen.  My
 > suggestion is that Reiterable should be define as an iteratable for
 > which calling the __iter__ method yields the same elements in the
 > same order irrespective of whether __iter__ is called while a
 > previously returned iterator is still iterating.

 > Correct me if I'm wrong, but views on dicts are reiterable.

For the same reason that sequences are: a view is not an iterator, so
every time you iterate it, it gets passed to iter, and you get a new
iterator, which then iterates.

This is *why* Nick says that "isinstance(x, Iterable) and not
isinstance(x, Iterator)" is the test you want.  I can't speak for Nick
on Steven A's example of an object with a __getitem__ taking a numeric
argument that isn't an Iterable but is iterable, but I think that
falls under "consenting adults" aka "if you're afraid it will hurt,

 > Your second point that the method should be able to cheaply clone
 > an iterator cheaply is precisely what I'd like to achieve with a
 > "Reiterator" class like Antoine's.

Well, I've kinda convinced myself that it isn't going to be easy to do
that, without changing the type.  The problem is that __next__ is
(abstractly) a closure, and there's no way I know of to copy a
function (copy.copy just returns the function object unchanged).  So
you'd need to expose the hidden state in the closure, and that is a
change of type.

 > It sounds like you're saying put the items into a list no matter
 > what.

No, I'm saying if you don't know if you may consume the iterable, you
should convert to iterator, clone the iterator, and iterate the
clone.  But that probably requires a change of type, at which point
you may as well call it "Reiterable".

More information about the Python-ideas mailing list