<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 27, 2017 at 3:49 PM, Greg Ewing <span dir="ltr"><<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">C Anthony Risinger wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* 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").<br>
</blockquote>
<br></span>
-1. There's a convention that an iterator can implement __len__<br>
to provide a hint about the number of items it will return<br>
(useful for preallocating space, etc.) It would be very<br>
annoying if such an iterator behaved differently from other<br>
iterators when unpacking.<br></blockquote><div><br></div><div>Is __len__ a viable option now that __length_hint__ has been identified for hints? IOW, if it's possible to know the full length of RHS ahead of time, and the LHS is also fixed width, then unpack like today else unpack lazily.</div><div><br></div><div>This does make unpacking behave slightly different if the RHS is `Sized` (per ABC, has __len__), but that doesn't seem too unreasonable. It's different after all.</div><div><br></div><div>Using Ellipsis, eg. `a, b, ... = it()`, seems like a OK approach too but it's unfortunate we are effectively working around the current force-matching behavior of unpacking... is this the appropriate default? Is there precedence or guidance elsewhere?</div><div><br></div><div>`a, b, ...` to me says "pull out a and b and throw away the rest", sort of like the spread operator in JS/ECMA. The mere presence of more characters (...) implies something else will *happen* to the remaining items, not that they will be skipped.</div><div><br></div><div>What about the explicit RHS unpacking idea? Kirill commented on this approach but I'm not sure others did:</div><div><div><br></div><div><div>>>> a, b = iter([1, 2, 3]); a, b</div><div>(1, 2)</div></div></div><div><br></div><div>>>> a, b = *iter([1, 2, 3]); a, b</div><div><div>Traceback (most recent call last):</div><div>  File "<stdin>", line 1, in <module></div><div>ValueError: too many values to unpack (expected 2)</div></div><div><br></div><div>This reads very clearly to me that the RHS is expected to be 100% unraveled, and would work with any iterable in the same way.</div><div><br></div><div>Thanks,</div></div>
</div></div>