>>> barr = bytearray(b'abcde')
>>> lst = list('abcde')
>>> barr[::-3] = ()
>>> barr
bytearray(b'acd')
>>> lst[::-3] = ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: attempt to assign sequence of size 0 to extended slice of size 2
>>> del lst[::-3]
>>> lst
['a', 'c', 'd']
>>>

lst[::-3] = () - is more convenient way for deletion

I happen to prefer del myself, but I agree that the two mutable sequence classes should behave the same. The manual 4.6.4 says

s[i:j:k] = t the elements of s[i:j:k] are replaced by those of t (1) 
1. t must have the same length as the slice it is replacing.

So the list behavior is not a bug. Extending its behavior is a feature request that could only happen in the 'next' release, now 3.3.

It is not usually considered a bug for something to do something beyond what is promised; in any case, you are *not* requesting that bytearrays be restricted as lists are. But that could be the fix to remove the 'bug' of inconsistency.  That also could not happen until a next release.

Since deletion of contiguous slices works and since deletion of extended slices can work and since I found the restriction slightly surprising, I am in favor of extending list behavior unless there is some internal reason why it cannot be.

The rationale for the restriction is that replacing a contiguous slice with a different number of items makes sense but replacing non-contiguous items with a different number does not -- except in the special case where the number is 0. So what you are really asking is that the footnote be changed to

1. t must have the same length as the slice it is replacing or be empty

That is the current behavior of bytearrays.

> I happen to prefer del myself
> but I agree that the two mutable sequence classes should behave the same.

del is not so flexible as assignement

>>> cmpr = [bytearray(i.encode('ascii')) for i in ('abcd', 'efgh', 'ijkl')]
>>> cmpr
[bytearray(b'abcd'), bytearray(b'efgh'), bytearray(b'ijkl')]
>>> cmpr[0][::-2] = cmpr[1][::2] = cmpr[2][1::2] = ()
>>> cmpr
[bytearray(b'ac'), bytearray(b'fh'), bytearray(b'ik')]
>>>

the former could be like:
del cmpr[0][::-2], cmpr[1][::2], cmpr[2][1::2]

it's ok

how to implement this with del ?
>>> cmpr
[bytearray(b'abcd'), bytearray(b'efgh'), bytearray(b'ijkl')]
>>> cmpr[0][::-2], cmpr[1][::2] = (), cmpr[2][1::2]
>>> cmpr
[bytearray(b'ac'), bytearray(b'jflh'), bytearray(b'ijkl')]
>>>

I'll have a try at this one.

I left some style comments in the rietveld review. However, a bigger questions is whether we should change list at all. I think we should; the change is fairly straightforward, there is some value in it and it's a good idea to keep bytearray and other mutable sequences behave similarly (and we can't remove the support from bytearray for obvious backward compatibility reasons.)

Thomas, could you take another look? I did update the patch.

Thanks! :)

Note that adding this new feature to list adds a pressure to add this feature to other mutable sequences (deque, ElementTree.Element, etc). This is a burden for maintainers.

array already supports this feature as well as bytearray. It may be a difference between arrays of unboxed values and general collections of Python objects.

Also memoryview() doesn't support:

>>> m = memoryview(bytearray(b'abcde'))
>>> m[::2] = ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' does not support the buffer interface
>>> m[::2] = b''
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview assignment: lvalue and rvalue have different structures
>>> m[::2] = b'123'
>>> m.tobytes()
b'1b2d3'
>>>