"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On 2008-05-08 22:55, Terry Reedy wrote: | > Functions that map unicode->unicode or bytes->bytes could be called | > transcoders. Each type could be given a .transcode method to go along with | > but contrast with .encode or .decode.
My main idea is that we can both keep current functionality *and* the new restriction on usage of .encode() and .decode() (which *does* make things less confusing at least for me). | Are you suggesting to have two separate methods which then | allow same-type-conversions ? One for encoding to the same | type and one for decoding ? I only suggested the possibility of one because I was thinking of transcoders more generally than those in definite 'encode'/'decode' pairs. A lossy encoder needs a decoder just to do the reverse type conversion. But a lossy transcoder whose natural partner is the identity function does not. At least not conceptually. (Example for bytes: map most control chars to 0 and any above 127 to 127.) Another difference is that transcoders can be chained is a way that encoders (or decoders, both in the class-changing sense) cannot. Thinking more, I realize that there are byte transcoders scattered across several modules and they are not going to be consolidated. Perhaps only unicode 'transcoders' are needed. But not for me to decide. | Fine with me. I do not really have a hat in this ring, so details are for others to decide. | They do have to map naturally to the codec method encode and | decode, though, so a single method won't do, unless maybe | you add a parameter to define the direction of the coding | process. It was an open question to me whether to reuse codecs or make a new transcoders module. But ditto my last comment. Terry Jan Reedy _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
