This proposal resonates with me. I've definitely wanted to use unpacking to crank an iterator a couple times and move on without exhausting the iterator. It's a very natural and intuitive meaning for unpacking as it relates to iterators.
In my mind, this ask is aligned with, and has similar motivation to, lazy zip(), map(), and keys() in Python 3. Syntax support for unpacking as it stands today is not very conducive to iterables and conflicts with a widespread desire to use more of them.
Couple thoughts:
* Perhaps existence of `__len__` should influence unpacking? There is a semantic difference (and typically a visual one too) between 1-to-1 matching a fixed-width sequence/container on the RHS to identifiers on the LHS, even if they look similar (ie. "if RHS has a length make it fit, otherwise don't").
* (related to above) Perhaps the "rigidity"(?) of both RHS and LHS should influence unpacking? If they are both fixed-width, expect exact match. If either is variable-width, then lazily unravel until a different problem happens (eg. LHS is fixed-width but RHS ran out of values... basically we always unravel lazily, but keep track of when LHS or RHS become variable, and avoid checking length if they do).
* Python 4 change as the language moves towards lazy iterators everywhere? If `__len__` influenced behavior like mentioned above, then a mechanical fix to code would simply be `LHS = tuple(*RHS)`, similar to keys().
While I like the original proposal, adding basic slice support to iterables is also a nice idea. Both are independently useful, eg. `gen.__getitem__(slice())` delegates to islice(). This achieves the goal of allowing meaningful unpacking of an iterator window, using normal syntax, without breaking existing code.
The fixed/variable-width idea makes the most sense to me though. This enables things like:
>>> a, b, c = (1, *range(2, 100), 3)
(1, 2, 3)
Since both sides are not explicitly sized unpacking is not forcibly sized either.
Expecting LHS/RHS to exactly match 100% of the time is the special case here today, not the proposed general unpacking rules that will work well with iterators. This change also has a Lua-like multiple return value feel to it that appeals to me.
Thanks,