<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">​What little documentation I could find, providing a stride on the assignment target for a list is supposed to trigger 'advanced slicing' causing element-wise replacement - and hence requiring that the source iterable has the appropriate number of elements.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default"><div class="gmail_default" style="font-family:monospace,monospace">>>> a = [0,1,2,3]</div><div class="gmail_default" style="font-family:monospace,monospace">>>> a[::2] = [4,5]</div><div class="gmail_default" style="font-family:monospace,monospace">>>> a</div><div class="gmail_default" style="font-family:monospace,monospace">[4, 1, 5, 3]</div><div class="gmail_default" style="font-family:monospace,monospace">>>> a[::2] = [4,5,6]</div><div class="gmail_default" style="font-family:monospace,monospace">Traceback (most recent call last):</div><div class="gmail_default" style="font-family:monospace,monospace">  File "<stdin>", line 1, in <module></div><div class="gmail_default" style="font-family:monospace,monospace">ValueError: attempt to assign sequence of size 3 to extended slice of size 2</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">This is in contrast to regular slicing (*without* a stride), allowing to replace a *range* by another sequence of arbitrary length.</div><div style="font-family:monospace,monospace"><br></div><div><div><font face="monospace, monospace">>>> a = [0,1,2,3]</font></div><div><font face="monospace, monospace">>>> a[:3] = [4]</font></div><div><font face="monospace, monospace">>>> a</font></div><div><font face="monospace, monospace">[4, 3]</font></div></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Issue</div><div style="font-family:monospace,monospace">=====</div><div style="font-family:monospace,monospace">When, however, a stride of `1` is specified, advanced slicing is not triggered.</div><div style="font-family:monospace,monospace"><br></div><div><div style="font-family:monospace,monospace">>>> a = [0,1,2,3]</div><div style="font-family:monospace,monospace">>>> a[:3:1] = [4]</div><div style="font-family:monospace,monospace">>>> a</div><div style="font-family:monospace,monospace">[4, 3]</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">If advanced slicing had been triggered, there should have been a ValueError instead.  </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Expected behaviour:</div><div style="font-family:monospace,monospace"><br></div><div><div><font face="monospace, monospace">>>> a = [0,1,2,3]</font></div><div><font face="monospace, monospace">>>> a[:3:1] = [4]</font></div><div><div><font face="monospace, monospace">Traceback (most recent call last):</font></div><div><font face="monospace, monospace">  File "<stdin>", line 1, in <module></font></div><div><font face="monospace, monospace">ValueError: attempt to assign sequence of size 1 to extended slice of size 3</font></div></div></div><div><br></div><div style="font-family:monospace,monospace">I think that is an inconsistency in the language that should be fixed.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Why do we need this?</div><div style="font-family:monospace,monospace">====================</div><div style="font-family:monospace,monospace">One may want this as extra check as well so that list does not change size.  Depending on implementation, it may come with performance benefits as well.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">One could, though, argue that you still get the same result if you do all correctly</div><div style="font-family:monospace,monospace"><br></div><div><div style="font-family:monospace,monospace">>>> a = [0,1,2,3]</div><div style="font-family:monospace,monospace">>>> a[:3:1] = [4,5,6]</div><div><div><font face="monospace, monospace">>>> a</font></div><div><font face="monospace, monospace">[4, 5, 6, 3]</font></div></div><div style="font-family:monospace,monospace"><br></div></div><div style="font-family:monospace,monospace">But I disagree that there should be no error when it is wrong.  </div><div style="font-family:monospace,monospace">*Strides that are not None should always trigger advanced slicing.*</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Other Data Types</div><div style="font-family:monospace,monospace">================</div><div style="font-family:monospace,monospace">This change should also be applied to bytearray, etc., though see below.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Concerns</div><div style="font-family:monospace,monospace">========</div><div style="font-family:monospace,monospace">It may break some code that uses advanced slicing and expects regular slicing to occur?  These cases should be rare, and the error message should be clear enough to allow fixes? I assume these cases should be exceptionally rare.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">If the implementation relies on `slice.indices(len(seq))[2] == 1` to determine about advance slicing or not, that would require some refactoring.  If it is only `slice.stride in (1, None)` then this could easily replaced by checking against None.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Will there be issues with syntax consistency with other data types, in particular outside the core library?  </div><div style="font-family:monospace,monospace">- I always found that the dynamic behaviour of lists w/r non-advanced slicing to be somewhat peculiar in the first place, though, undeniably, it can be immensely useful.  </div><div style="font-family:monospace,monospace">- Most external data types with fixed memory such as numpy do not have this dynamic flexibility, and the behavior of regular slicing on assignment is the same as regular slicing.  The proposed change would increase consistency with these other data types.</div><div style="font-family:monospace,monospace"><br></div></div><div style="font-family:monospace,monospace">More surprises</div><div style="font-family:monospace,monospace">==============</div><div><div style="font-family:monospace,monospace">>>> import array</div><div><div><font face="monospace, monospace">>>> a[1::2] = a[3:3]</font></div><div><font face="monospace, monospace">Traceback (most recent call last):</font></div><div><font face="monospace, monospace">  File "<stdin>", line 1, in <module></font></div><div><font face="monospace, monospace">ValueError: attempt to assign sequence of size 0 to extended slice of size 2</font></div></div><div style="font-family:monospace,monospace"><br></div></div><div style="font-family:monospace,monospace">whereas</div><div style="font-family:monospace,monospace"><br></div><div><div style="font-family:monospace,monospace">>>> a = [1,2,3,4,5]</div><div style="font-family:monospace,monospace">>>> a[1::2] = a[3:3]</div><div style="font-family:monospace,monospace">Traceback (most recent call last):</div><div style="font-family:monospace,monospace">  File "<stdin>", line 1, in <module></div><div style="font-family:monospace,monospace">ValueError: attempt to assign sequence of size 0 to extended slice of size 2</div><div style="font-family:monospace,monospace"><br></div><div><div><font face="monospace, monospace">>>> a = bytearray(b'12345')</font></div><div><span style="font-family:monospace,monospace">>>> a[1::2] = a[3:3]</span><br></div><div><font face="monospace, monospace">>>> a</font></div><div><font face="monospace, monospace">bytearray(b'135')</font></div></div><div style="font-family:monospace,monospace"><br></div></div><div style="font-family:monospace,monospace">but numpy</div><div style="font-family:monospace,monospace"><br></div><div><div style="font-family:monospace,monospace">>>> import numpy as np</div><div style="font-family:monospace,monospace">>>> a = np.array([1,2,3,4,5])</div><div style="font-family:monospace,monospace">>>> a[1::2] = a[3:3]<br></div><div style="font-family:monospace,monospace">Traceback (most recent call last):</div><div style="font-family:monospace,monospace">  File "<stdin>", line 1, in <module></div><div style="font-family:monospace,monospace">ValueError: could not broadcast input array from shape (0) into shape (2)</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">and</div><div style="font-family:monospace,monospace"><br></div><div><div><font face="monospace, monospace">>>> import numpy as np</font></div><div><font face="monospace, monospace">>>> a[1:2] = a[3:3]</font></div><div><font face="monospace, monospace">Traceback (most recent call last):</font></div><div><font face="monospace, monospace">  File "<stdin>", line 1, in <module></font></div><div><font face="monospace, monospace">ValueError: could not broadcast input array from shape (0) into shape (1)</font></div></div><div style="font-family:monospace,monospace"><br></div></div><div style="font-family:monospace,monospace">The latter two as expected.  memoryview behaves the same.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Issue 2</div><div style="font-family:monospace,monospace">=======</div><div style="font-family:monospace,monospace">Whereas NumPy is know to behave differently as a data type with fixed memory layout, and is not part of the standard library anyway, the difference in behaviour between lists and arrays I find disconcerting.  This should be resolved to a consistent behaviour.  </div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Proposal 2</div><div style="font-family:monospace,monospace">==========</div><div style="font-family:monospace,monospace">Arrays and bytearrays should should adopt the same advanced slicing behaviour I suggest for lists.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Concerns 2</div><div style="font-family:monospace,monospace">==========</div><div style="font-family:monospace,monospace">This has the potential for a lot more side effects in existing code, but as before in most cases error message should be triggered.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">Summary</div><div style="font-family:monospace,monospace">=======</div><div style="font-family:monospace,monospace">I find it it not acceptable as a good language design that there is a large range of behaviour  on slicing in assignment target for the different native (and standard library) data type of seemingly similar kind, and that users have to figure out for each data type by testing - or at the very least remember if documented - how it behaves on slicing in assignment targets.  There should be a consistent behaviour at the very least, ideally even one with a clear user interface as suggested for lists.</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace">-Alexander</div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div><div style="font-family:monospace,monospace"><br></div></div></div>