Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> Any Python object can expose a buffer interface and the above
>> functions then allow accessing these interfaces from within
>> Python.
> 
> What's the point? The codecs functions already support objects exposing the buffer interface:
> 
>>>> b = b"\xe9"
>>>> codecs.latin_1_decode(memoryview(b))
> ('é', 1)
>>>> codecs.latin_1_decode(array.array("b", b))
> ('é', 1)
>
> Those two functions are undocumented. They serve no useful purpose (you can call the bytes(...) constructor instead, or even use the buffer object directly as showed above). They are badly named since they don't have anything to do with codecs. Google Code Search shows them not appearing anywhere else than implementations of the Python stdlib. Removing them only seems reasonable.

readbuffer_encode and charbuffer_encode convert objects to bytes
and provide a codec encoder interface for this, hence the naming.

They are meant to be used as encode methods for codecs, just like
the other *_encode functions exposed in the _codecs module, e.g.

class BinaryDataCodec(codecs.Codec):

    # Note: Binding these as C functions will result in the class not
    # converting them to methods. This is intended.
    encode = codecs.readbuffer_encode
    decode = codecs.latin_1_decode

While it's possible to emulate the functions via other methods,
these methods always introduce intermediate objects, which isn't
necessary and only costs performance.

Given than "t#" was basically rendered useless in Python3 (see
issue8839), removing charbuffer_encode() is indeed possible,
so

+1 on removing charbuffer_encode()
-1 on removing readbuffer_encode()