[Python-ideas] Consider making enumerate a sequence if its argument is a sequence

Andrew Barnert abarnert at yahoo.com
Thu Oct 1 04:31:23 CEST 2015


On Sep 30, 2015, at 19:04, Akira Li <4kir4.1i at gmail.com> wrote:
> 
> Random832 <random832 at fastmail.com> writes:
> 
>> Akira Li <4kir4.1i at gmail.com> writes:
>> 
>>> Andrew Barnert via Python-ideas
>>> <python-ideas at python.org> writes:
>>> ...
>>>> (The fact that we don't have a term for "non-iterator iterable", and
>>> 
>>> All iterators are iterable but some iterables are not iterators.
>>> 
>>> If your code accepts only iterators then use the term *iterator*.
>>> Otherwise the term *iterable* could be used.
>>> 
>>> It is misleading to use *iterable* if your code only accepts iterators.
>>> 
>>> If an iterable is an iterator; It is called *iterator*. The term
>>> *iterable* implies that some instances are not iterators.
>> 
>> There are three (well, three and a half) kinds of code that consume
>> iterables, how would you describe each simply?
>> 
>> 1. Does not call iter, simply calls next. Therefore cannot consume a
>>   non-iterator iterable.
> iterator
> 
>> 2. Calls iter, but can accept an iterator (e.g. only goes through it
>>   once)
> iterable
> 
>> 3. Cannot accept an iterator (goes through it twice, or permanently
>>   stores a reference to it, etc)
> neither
> 
> *iterable* is an object that you can pass to iter() to get *iterator*.
> An iterable does not guarantee that it yields the same items twice.

And this is exactly the problem. We don't have any way to simply describe this thing. Hence all the confusion in this thread, and in similar discussions elsewhere, and even in the docs (e.g., describing dict views as sequences and then going on to explain that they're not actually sequences).

The fact that it took your previous message four paragraphs without inventing a new term, to say what I said in one sentence with a new term, demonstrates the problem. As does the fact that my attempted new term, "non-iterator iterable", is sufficiently ugly and not intuitively helpful enough that you felt the need to expand on it for four paragraphs.


More information about the Python-ideas mailing list