<div dir="ltr"><div dir="ltr"><div><div>Currently during assignment, when target list is a comma-separated list of targets (<b>without "starred" target</b>) the rule is that the object (<span style="font-family:monospace,monospace">rhs</span>) must be an <span style="font-family:monospace,monospace">iterable</span>
 with the same number of items as there are targets in the target list. 
That is, no check is performed on the number of targets present, and if 
something goes wrong the  <span style="font-family:monospace,monospace">ValueError</span> is raised. To show this on simple example:<br><br><span style="font-family:monospace,monospace">>>> from itertools import count, islice<br>>>> it = count()<br>>>> x, y = it<br>>>> it<br>count(3)<br><br></span><span style="font-family:arial,helvetica,sans-serif">Here the <span style="font-family:monospace,monospace">count</span> was advanced two times but assignment did not happen. I found that in some cases it is too much restricting that <span style="font-family:monospace,monospace">rhs</span> must have the same number of items as targets. It is proposed that if the <span style="font-family:monospace,monospace">rhs</span> is a <span style="font-family:monospace,monospace">generator</span> or an <span style="font-family:monospace,monospace">iterator</span>
 (better some object that yields values on demand), the assignmenet 
should be lazy and dependent on the number of targets. I find this 
feature to be very convenient for interactive use, while it remains 
readable, expected, and expressed in a more compact code.</span><span style="font-family:monospace,monospace"><br></span><span style="font-family:arial,helvetica,sans-serif"><br>There are some Pros:<br>    1. No overhead<br>    2. Readable and not so verbose code<br>    3. Optimized case for<span style="font-family:monospace,monospace"> x,y,*z = iterator</span><br>    4. Clear way to assign values partially from infinite <span style="font-family:monospace,monospace">generators</span>.<br>    <br>Cons:<br>    1. A special case of how assignment works<br>    2. As with any implicit behavior, hard-to-find bugs</span><span style="font-family:monospace,monospace"><br><br></span><span style="font-family:arial,helvetica,sans-serif">There several cases with "undefined" behavior:<br>1. Because the items are assigned, from left to right to the corresponding targets, should <span style="font-family:monospace,monospace">rhs</span> see side effects during assignment or not?<br>2. Should this work only for <span style="font-family:monospace,monospace">generators</span> or for any <span style="font-family:monospace,monospace">iterators</span>?<br>3. Is it Pythonic to distinguish what is on the <span style="font-family:monospace,monospace">rhs</span> during assignment, or it contradicts with duck typing (goose typing)?</span><span style="font-family:monospace,monospace"><br><br></span><span style="font-family:arial,helvetica,sans-serif">In many cases it is possible to do this right now, but in too verbose way:</span><span style="font-family:monospace,monospace"><br><br>>>> x, y = islice(gen(), 2)<br><br></span><span style="font-family:arial,helvetica,sans-serif">But it seems for me that:</span><span style="font-family:monospace,monospace"><br><br>>>> x, y = gen()<br></span><br>Looks the same, easy to follow and not so verbose. Another case, which is a pitfall, but will be possible:<span style="font-family:monospace,monospace"><br><br>>>> x, y = iter([0,1,2,3,4]) # Now it is Ok<br></span></div><span style="font-family:monospace,monospace">>>> x<br>1<br></span></div><span style="font-family:monospace,monospace">>>> y<br>2<br></span><div><div><span style="font-family:arial,helvetica,sans-serif"><br>But</span><span style="font-family:monospace,monospace">:<br><br>>>> x, y = [0,1,2,3,4]       # raises ValueError<br><br></span><span style="font-family:arial,helvetica,sans-serif">Any thoughts?<br><br>With kind regards, -gdg</span></div></div></div></div>