>>> a = bytearray()
>>> a[:] = 0 # Is it a feature?
>>> a
bytearray(b'')
>>> a[:] = 10 # If so, why not document it?
>>> a
bytearray(b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
>>> a[:] = -1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: negative count
>>> a[:] = -1000000000000000000000 # This should raise ValueError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = 1000000000000000000
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> a[:] = 1000000000000000000000 # This should raise OverflowError, not TypeError.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> a[:] = [] # Are some empty sequences better than others?
>>> a[:] = ()
>>> a[:] = list("")
>>> a[:] = ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

It looks rather like a bug to me, and should be forbidden.

pitrou: I agree, it should be a TypeError.

This happens because bytearray_ass_subscript() (Objects/bytearrayobject.c:588) calls PyByteArray_FromObject() (:641) that in turn calls bytearray_init() (:746), so the results are similar to the ones returned by calling bytearray(...) directly.

Here is a proof of concept that fixes the problem.

The doc of bytearray() says about its first arg:
 * If it is a string, you must also give the encoding [...].
 * If it is an integer, the array will have that size and will be initialized with null bytes.
 * If it is an object conforming to the buffer interface, a read-only buffer of the object will be used to initialize the bytes array.
 * If it is an iterable, it must be an iterable of integers in the range 0 <= x < 256, which are used as the initial contents of the array.

All these things except the string[1] and the integer seem OK to me while assigning to a slice, so in the patch I've special-cased ints to raise a TypeError (it fails already for unicode strings).

[1]: note that string here means unicode string (the doc should probably be more specific about it.). Byte strings work fine, but for unicode strings there's no way to specify the encoding while doing ba[:] = u'ustring'.

Empty string is an iterable of integers in the range 0 <= x < 256, so it should be allowed.

>>> all(isinstance(x, int) and 0 <= x < 256 for x in "")
True
>>> bytearray()[:] = ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: string argument without an encoding

Not really, chars are not ints and anyway the empty string fall in the first case.

> Not really, chars are not ints
Yes, however, empty string contains exactly zero chars.
> and anyway the empty string fall in the first case.
Strings aren't mentioned in documentation of bytearray slice assignment. However, I think that bytearray constructor should accept empty string too, without an encoding, for consistency.

__doc__ of bytearray says:
> bytearray(iterable_of_ints) -> bytearray
> bytearray(string, encoding[, errors]) -> bytearray
> bytearray(bytes_or_bytearray) -> mutable copy of bytes_or_bytearray
> bytearray(memory_view) -> bytearray
So, unless an encoding is given, empty string should be interpreted as an iterable of ints. BTW, documentation and docstring should be made consistent with each other.

-1 on assigning strings to slices of bytearrays. As Ezio mentions, this operation conceptually requires an encoding, and no encoding is readily available in the slice assignment.

-1 on special-casing empty strings.

-1 on special-casing string without an encoding. Current code does (almost) this:
...
if argument_is_a_string:
	if not encoding_is_given: # Special case
		raise TypeError("string argument without an encoding")
	encode_argument()
	return
if encoding_is_given:
	raise TypeError("encoding or errors without a string argument")
...
IMO, it should do this instead:
...
if encoding_is_given:
	if not argument_is_a_string:
		raise TypeError("encoding or errors without a string argument")
	encode_argument()
	return
...
This way, bytearray("") would work without any special cases.

Python is not (e.g.) Haskell; Python strings are not lists whose contents happen to be characters.  Allowing an empty string here is a step backwards in the direction of "why not allow any string whose contents have an unambiguous meaning as bytes", i.e. the default encoding ASCII in Python 2.x.  Passing a string where bytes are expected is a programming error, and it should be rewarded with an exception, no matter if the string happens to be empty or not.

> >>> a[:] = -1000000000000000000000 # This should raise ValueError, not TypeError.
> >>> a[:] = 1000000000000000000000 # This should raise OverflowError, not TypeError.

FTR, these two now raise OverflowError.

Updated patch against default.

The new patch further improve tests and error message, checking for both numbers and strings:

>>> b = bytearray(b'fooooooo')
>>> b[3:4] = 'foo'
TypeError: can assign only bytes, buffers, or iterables of ints in range(0, 256)
>>> b[3:4] = 5
TypeError: can assign only bytes, buffers, or iterables of ints in range(0, 256)
>>> b[3:4] = 5.2
TypeError: can assign only bytes, buffers, or iterables of ints in range(0, 256)
>>> b[3:4] = None
TypeError: 'NoneType' object is not iterable


Before the patch these errors were reported instead:

>>> b = bytearray(b'fooooooo')
>>> b[3:4] = 'foo'  # can't provide encoding here
TypeError: string argument without an encoding
>>> b[3:4] = 5  # this "worked"
>>> b[3:4] = 5.2
TypeError: 'float' object is not iterable
>>> b[3:4] = None
TypeError: 'NoneType' object is not iterable

The patch looks fine to me.

New changeset 1bd2b272c568 by Ezio Melotti in branch '2.7':
#8401: assigning an int to a bytearray slice (e.g. b[3:4] = 5) now raises an error.
http://hg.python.org/cpython/rev/1bd2b272c568

New changeset 8f00af8abaf9 by Ezio Melotti in branch '3.2':
#8401: assigning an int to a bytearray slice (e.g. b[3:4] = 5) now raises an error.
http://hg.python.org/cpython/rev/8f00af8abaf9

New changeset 06577f6b1c99 by Ezio Melotti in branch '3.3':
#8401: merge with 3.2.
http://hg.python.org/cpython/rev/06577f6b1c99

New changeset db40752c6cc7 by Ezio Melotti in branch 'default':
#8401: merge with 3.3.
http://hg.python.org/cpython/rev/db40752c6cc7

New changeset a7ebc0db5c18 by Ezio Melotti in branch 'default':
Merge typo fixes (and the fix for #8401 that I wrongly merged) with 3.3.
http://hg.python.org/cpython/rev/a7ebc0db5c18