[Python-ideas] Introduce collections.Reiterable

[Nick Coghlan]

On 22 September 2013 18:58, Georg Brandl <g.brandl at gmx.net> wrote:
> On 09/22/2013 06:56 AM, Nick Coghlan wrote:
>> On 20 Sep 2013 19:49, "Steven D'Aprano" <steve at pearwood.info> wrote:
>>> I don't think this is a critical distinction. I think it is fine to call
>>> views "iterable", since they can be iterated over. On the rare occasion
>>> that it matters, we can just do what I did above, and talk about objects
>>> which are directly iterable (e.g. iterators, sequences, generator
>>> objects) and those which are indirectly iterable (e.g. dict views).
>>
>> Or you could just use the existing terminology and talk about
>> iterables vs iterators instead of inventing your own terms.
>
> Ack. Please don't create new terms, rather suggest an improvement to the
> glossary definition if you think it's inadequate.

As near as I can tell, Steven's observation is that, for backwards
compatibility reasons, iter() tolerates sequences that define __len__
and __getitem__ without defining __iter__, whereas the collections
ABCs require an __iter__ method for their ducktyping to trigger. This
means that there are a small number of legacy cases where
"isinstance(c, collections.abc.Iterable)" can be False, while calling
"iter(c)" would still give you a working iterator.

My take on it is that when Guido formalised the container model in PEP
3119, he was *deliberately* relegating those "iterable without
defining __iter__" cases to be purely a backwards compatibility hack
without forming part of the formal object model. The class definitions
that aren't defining the full Sequence ABC (including __iter__) aren't
really proper sequences in Python 3, even though they'll still mostly
work (thanks to the prevalence of ducktyping).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia