<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Couple thoughts:</div><div dir="auto"><br></div><div dir="auto">* 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").</div><div dir="auto"><br></div><div dir="auto">* (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).</div><div dir="auto"><br></div><div dir="auto">* 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().</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">The fixed/variable-width idea makes the most sense to me though. This enables things like:</div><div dir="auto"><br></div><div dir="auto">>>> a, b, c = (1, *range(2, 100), 3)</div><div dir="auto">(1, 2, 3)</div><div dir="auto"><br></div><div dir="auto">Since both sides are not explicitly sized unpacking is not forcibly sized either.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 27, 2017 10:23 AM, "Paul Moore" <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27 November 2017 at 16:05, Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
> On Tue, Nov 28, 2017 at 2:35 AM, Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br>
>> In this case, there is a small but real benefit to counting the<br>
>> assignment targets and being explicit about the number of items to<br>
>> slice. Consider an extension to this "non-consuming" unpacking that<br>
>> allowed syntax like this to pass silently:<br>
>><br>
>>     a, b = x, y, z<br>
>><br>
>> That ought to be a clear error, right? I would hope you don't think that<br>
>> Python should let that through. Okay, now we put x, y, z into a list,<br>
>> then unpack the list:<br>
>><br>
>>     L = [x, y, z]<br>
>>     a, b = L<br>
>><br>
>> That ought to still be an error, unless we explicity silence it. One way<br>
>> to do so is with an explicit slice:<br>
>><br>
>>     a, b = L[:2]<br>
><br>
> I absolutely agree with this for the default case. That's why I am<br>
> ONLY in favour of the explicit options. So, for instance:<br>
><br>
> a, b = x, y, z # error<br>
> a, b, ... = x, y, z # valid (evaluates and ignores z)<br>
<br>
Agreed, only explicit options are even worth considering (because of<br>
backward compatibility if for no other reason). However, the unpacking<br>
syntax is already complex, and hard to search for. Making it more<br>
complex needs a strong justification. And good luck in doing a google<br>
search for "..." if you saw that code in a project you had to<br>
maintain. Seriously, has anyone done a proper investigation into how<br>
much benefit this proposal would provide? It should be reasonably easy<br>
to do a code search for something like "=.*islice", to find code<br>
that's a candidate for using the proposed syntax. I suspect there's<br>
very little code like that.<br>
<br>
I'm -1 on this proposal without a much better justification of the<br>
benefits it will bring.<br>
Paul<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div></div>