STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> r81854 removes codecs.charbuffer_encode() (and t# parsing format) from Python 3.2 (blocked in 3.1: r81855).
> 
> --
> 
> My problem with codecs.readbuffer_encode() is that it does accept byte *and* character strings. If you want to get a byte string, just use bytes(input). If you want to convert a character string to a byte string, use input.encode("utf-8"). But accepting both types may lead to mojibake as we had in Python2.

The point is to have an interface to the "s#" parser marker
from Python. This accepts bytes, objects with a buffer interface
and Unicode objects (via the default encoding).

It does not accept e.g. lists, tuples or plain integers like
bytes() does.

> MAL> That's a common misunderstanding. The codec system does not
> MAL> mandate a specific type combination. Only the helper methods
> MAL> .encode() and .decode() on bytes and str objects in Python3 do.
> 
> This is related to #7475: we have to decide if we drop completly this  (currently unused) feature (eg. remove codecs.readbuffer_encode()), or if we "reenable" this feature again (reintroduce hex, bz2, rot13, ... codecs). This discussion should occur on the mailing list.

We are not going to drop this design feature of the codec system
and we've already had the discussion in 2008.

The statement that it is an unused feature is plain wrong. Please
don't forget that people are actually using these things in their
applications, many of which have not been ported to Python3.
We're not just talking about code that you find in CPython or the
stdlib.

The removed codecs will go back into 3.2.