[Python-ideas] Generator unpacking

[Andrew Barnert]

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:

> (And of course in my first attempt I forgot I needed iter(range(...))
> as range is not a pure iterable - proving my point about the subtle
> semantics!)

Ranges are as iterable as both lists and iterators. You're a smart guy, and you know Python. So why do you make this mistake? Because you don't have a term to fit "range" into, so your brain struggles between two prototypes--is it like a list, or like a generator? Well, it's lazy, so it's like a generator, so you don't need to call iter here, right? Nope.

This is the same as the experiment where they give people the English cousin rule and asked them to evaluate which family relationships count as cousins. People whose native language has no word for "cousin"--e.g., because they have unrelated words for "maternal cousin" and "paternal cousin"--make a lot more mistakes than people whose language has a word that matches the rule.