[Python-3000] PEP 3138- String representation in Python 3000

[Terry Reedy]

"M.-A. Lemburg" <mal at egenix.com> wrote in message 
news:48242D4A.3060802 at egenix.com...
| 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