Eli Bendersky <eli...@gmail.com> added the comment:
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?
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12380>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
