[Python-ideas] Introduce collections.Reiterable

Andrew Barnert abarnert at yahoo.com
Sun Sep 22 21:23:43 CEST 2013

```On Sep 22, 2013, at 9:28, Terry Reedy <tjreedy at udel.edu> wrote:

> On 9/21/2013 10:05 PM, Andrew Barnert wrote:
>> On Sep 21, 2013, at 15:31, Terry Reedy
>> <tjreedy at udel.edu> wrote:
>>
>>> On 9/21/2013 5:14 PM, Neil Girdhar wrote:
>>>
>>>> If you really think that there will never be a non-reiterable
>>>> non-iterator iterable,
>>>
>>> I already posted a sensible non-iterator iterable that is no more
>>> reiterable than an iterator.
>
> class Cnt:
>    def __init__(self, maxn):
>        self.n = 0
>        self.maxn = maxn
>    def __getitem__(self, dummy):
>        n = self.n + 1
>        if n <= self.maxn:
>            self.n = n
>            return n
>        else:
>            raise IndexError

But this is a silly class, not a reasonable one. Why would you ever write this class, except to deceive users of it? It's more complicated and more verbose than an equivalent iterator, or the equivalent sequence (which you'd spell "range(n)", and the only "benefit" is that it pretends not to be an iterator.

You can just as easily write something that claims to be a sequence but iterates it's elements in random order; that wouldn't prove that sequences are unordered, just that the ABCs don't test for all possible incorrect semantics.

> c3 = Cnt(3)
> print(c3 is not iter(c3), list(c3), list(c3))
> >>>
> True [1, 2, 3] []
>
> The only difference between this and an equivalent iterator is that True would instead be False. I would not call this reiterable, unless one says that all iterables, including exhausted iterators, are reiterable, because you can always call iter on them again and do a null iteration.
>
> While I sympathize with the desire to classify, there is a reason why the inventors of the newer protocol left boundedness and reiterablity to negotiation between writers and users of functions taking iterable args. They were not unaware of the issues and problems that have been discussed in this thread.
>
>> You posted a long discussion of different ways in which "reiterable"
>> could be defined, and gave vague examples of things that are
>> reiterable in one sense but not in another. Accepting all of that at
>> face value, there's no way Neil's Reiterable ABC would help that
>> problem, because it would obviously only cover one of the possible
>> senses.
>
> We agree on the last sentence.
>
>> Beyond that, I've looked through your posts on that thread, and I
>> can't find anything that looks like a sensible non-iterator
>> non-reiterable (in Neil's intended sense) iterable. Did I miss
>> something?
>
> See above, though I do not know that Neil's intended sense is, or if indeed he has exactly one intended sense.
>
>>> I expect that there are examples in the wild.  If nothing else,
>>> there are probably some written before the new iterator protocol
>>> was added. These are explicitly supported.
>