homepage

>>> bytearray(b'abc').rjust(10, b'*')
bytearray(b'*******abc')
>>> bytearray(b'abc').rjust(10, bytearray(b'*'))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: must be a byte string of length 1, not bytearray
>>>

What's the use case? I'm inclined to reject this as not needed.

all other methods support it and it's right
>>> barr = bytearray(b'abcd*')
>>> barr.center(len(barr) * 4, barr[-1:])
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
TypeError: must be a byte string of length 1, not bytearray
>>> b = b'abcd*'
>>> b.center(len(b) * 4, b[-1:])
b'*******abcd*********'
>>>

A bytearray is for working with mutable data. We don't support using it in all places that the non-mutable data types can be used. You can code your example like this:
 barr.center(len(barr) * 4, bytes([barr[-1]]))
I realize that isn't particularly pretty, but that has more to do with the fact that indexing bytes gives you ints in Python 3 than it does with whether or not bytearray is accepted.
The data type of the arguments to the method have no necessary relationship with the datatype of the object.
You may have more success arguing that the fill character for both bytearray and bytes should be allowed to be an int.
I think this whole topic is better addressed in a forum such as python-ideas. I agree that the bytes interface is a bit wonky in places, but I think that if changes are going to be made a consensus needs to be developed on what changes to make. I believe some conversations about this have already taken place, and so far I don't think there are any consensus proposals.
So, I'm going to close this issue. But please join (or start, if necessary) the discussion on this wider topic in the appropriate forum.

> A bytearray is for working with mutable data. We don't support using > it in all places that the non-mutable data types can be used.
>>> bytearray(b'abcd').strip(bytearray(b'da'))
bytearray(b'bc')
>>>
.translate, .find, .partition, ...
>>> bytearray(b'.').join((bytearray(b'a'), bytearray(b'b')))
bytearray(b'a.b')
>>> bytearray(b'.').join((b'a', b'b'))
bytearray(b'a.b')
>>>
all these methods could use only bytes objects

All right, let's get some other opinions from people who have actually worked with the bytearray and bytes code (and Terry because he cares about APIs).

After thinking about this awhile, I see the key sentence of David's reply as "The data type of the arguments to the method have no necessary relationship with the datatype of the object." While true in general, in it not true with respect to corresponing text (string) and byte(array) methods. String parameters of strings methods become byte parameters of byte(array) methods. In the other hand, I think I agree with David's application to byte versus bytearray methods. I might change my mind after further examination of the methods in question. But for the present, I would not change the code.
Or would I? Here is a reason not to change. Example:
for byt in (b'abc', bytearray(b'cdef'), b'xye')
 yield byt.rjust(10,b'-')
Making the type of constant args depend on the type of the base object would make generic byte/bytearray functions more difficult. We already have this problem with writing functions that work with bytes and text in 3.x. It is a big nuisance that is only justified by the benefits of not mixing bytes and text. I do not think we should extend the nuisance to byte and bytearray functions, especially without a strong use case.
I marked this for 'documentation' because I think the doc for some of the str methods might be improved and that the reference to them in the bytes/bytearray definitely needs more. Doc changes would apply to 3.2 also.
"Bytes and bytearray objects, being "strings of bytes", have all methods found on strings, with the exception ... " 
should be followed by something like. 
"If the string method has a string parameter, the corresponding byte/bytearray method has a corresponding byte parameter."
(to match the reported current behavior).
I have not yet looked at doc strings. I did not unmark 'Interpreter core' because I have not looked at all of p.u's examples to be sure that I like *all* of the current behaviors.

I do agree it is a nuisance that it doesn't work with bytearray instances. After all, these methods are supposed to be homogeneous, and they are when called on a str or bytes object.

On one hand, I agree that the situation isn't intuitive. Why should some methods of bytearray accept bytearrays, and some shouldn't?
On the other hand, this actually has rather deep implementation reasons. 
Methods like 'translate' are implemented in Objects/bytearrayobject.c
On the other hand, ljust, rjust and center are taken from stringlib. Now, stringlib is generic code, and has some strict argument checking. For example, in stringlib_ljust:
 if (!PyArg_ParseTuple(args, "n|c:ljust", &width, &fillchar))
 return NULL;
The 'c' format to PyArg_ParseTuple expects an object that passes PyBytes_Check, IOW a bytes object or a subclass thereof. bytearray is not a subclass of bytes, hence the problem.
The solution could be global, to allow bytearray fit the 'c' format of PyArg_ParseTuple. Then one would also be able to pass a bytearray into other stringlib methods requiring the 'c' format.
One way or the other, this is of course doable. A decision has to be made though - is the nuisance annoying enough to warrant such an API change?

> The solution could be global, to allow bytearray fit the 'c' format of
> PyArg_ParseTuple. Then one would also be able to pass a bytearray into
> other stringlib methods requiring the 'c' format.
Another possibility would be the change the 'c' format so that it accepts any object that supports the buffer protocol and whose buffer length is 1.
Attaching two patches: The first allows bytes and bytearray, the second allows any object that supports the buffer protocol.

c_format_bytearray.patch looks ok to me. The other proposal is too broad, and may lead to confusing behaviour.
In any case, some tests are needed.

Updated the bytearray patch to change documentation and add tests.

Looks good. How about also adding some tests for the original request of supporting bytearrays in ljust/rjust/center?

Updated the patch to add tests for {bytes,bytearray}.{center,ljust,rjust}. The tests check that both bytes and bytearray are always accepted as the fill character.

New changeset 536fccc75f5a by Eli Bendersky in branch 'default':
Issue #12380: PyArg_ParseTuple now accepts a bytearray for the 'c' format.
http://hg.python.org/cpython/rev/536fccc75f5a 

Petri, thanks for the patch. I've updated Misc/NEWS and committed it.
Unless there are objections or problems, I will close this issue in a day or two.