Marc-Andre Lemburg <m...@egenix.com> added the comment: Martin v. Löwis wrote: > > Martin v. Löwis <mar...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7475> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
