Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> So, after reading the above comments, I think we may end up with
>> following changes:
>>  * restore the "bytes-to-bytes" codecs in the "encodings" package

+1

>>  * then create new helpers on bytes objects (either
>>    ".transform()/.untransform()" or ".encodebytes()/.decodebytes")

+1 - the names are still up for debate, IIRC.

> I would still be opposed to such a change, and I think it needs a PEP.

All this has already been discussed and the only reason it didn't
go in earlier was timing. No need for a PEP.

> If the codecs are restored, one half of them becomes available to
> .encode/.decode methods, since the codec registry cannot tell which
> ones implement real character encodings, and which ones are other
> conversion methods. So adding them would be really confusing.

Not at all. The helper methods check the return types and raise an
exception if the types don't match the expected types.

The codecs registry itself doesn't need to know about the possible
input/output types of codecs, since this information is not
required to match a name to an implementation.

What we could do, is add that information to the CodecInfo object
used for registering the codec. codecs.lookup() would then
return the information to the application.

E.g.

.encode_input_types = (str,)
.encode_output_types = (bytes,)
.decode_input_types = (bytes,)
.decode_output_types = (str,)

Codecs not supporting these CodecInfo attributes would simply
return None.

> I also wonder why you are opposed to the import statement. My
> recommendation is indeed that you use the official API for these
> libraries (and indeed, there is an official API for each of them,
> unlike real codecs, which don't have any other documented API).

That's not the point. The codec API provides a standardized API for
all these encodings. The hex, zlib, bz2, etc. codecs are just
adapters of the different pre-existing APIs to the codec API.