[Python-ideas] Generator unpacking

[Brendan Barnwell]

On 2016-02-15 00:39, Andrew Barnert via Python-ideas wrote:
> On Feb 15, 2016, at 00:12, Paul Moore <p.f.moore at gmail.com> wrote:
>>
>> IMO, the other downside is that the semantic difference between
>>
>> a, b, ... = value
>>
>> and
>>
>> a, b, *_ = value
>>
>> is very subtle, and (even worse) only significant if value is an
>> iterable as opposed to a concrete container such as a list.
>
> You mean iterator, not iterable. And being "concrete" has nothing to
> do with it--a dict view, a memoryview, a NumPy slice, etc. aren't
> iterators any more than a list is.
>
> This is exactly why I think we need an official term like
> "collection" for "iterables that are not iterators" (or "iterables
> whose __iter__ doesn't return self" or similar). People struggling to
> come up with terms end up confusing themselves--not just about
> wording, but about actual concepts. As proven below:

	I still don't think that is at all what we need, as this example shows. 
  Whether the value is an iterable or an iterator is not relevant. 
Whether the iterable's iterator is self is not relevant.  What is 
relevant is the difference in *behavior* --- namely, whether you can 
rewind, restart, or otherwise retrieve already-obtained values from the 
object, or whether advancing it is an irreversible operation and there 
is no way to get old values except by storing them yourself.  In this 
example, being able to say that value was or was not an iterator or an 
iterable would in no way help to clarify how the code would behave 
differently.  Saying that it is an iterable or an iterator is just 
saying that it has or doesn't have .next() and/or .__iter__() methods 
that follow certain very broad protocols, but what matters for 
understanding examples like this is what those methods actually DO.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no
path, and leave a trail."
    --author unknown