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

[Joel Bender]

Martin v. Löwis wrote:

> And that's the main difference why having encode/decode is a good idea,
> and having transform/untransform is a bad idea.

I agree that 'untransform' is a bad name for the inverse of transform, 
but I don't think 'transform' is bad.  For me the distinction is 
existence of a 'model'.

     sequence -> model -> sequence

...is different than...

     sequence -> sequence

where 'sequence' is a string, bytes or stream.  In transformations there 
is no intermediate model.

> OTOH, these things have often more complex parameters than just
> a name; e.g. the compressors also take a compression level. In
> these cases, using
> 
>   output_to = compressors[name](compresslevel=complevel)
> 
> could work fine (as both might happen to support the compresslevel
> keyword argument).

Your example seems to indicate a model->sequence operation, that I would 
call 'encode'.  Now the question becomes, given 'f', what makes more sense:

     (a)  y = x.transform(f)
     (b)  y = x.encode(f)
     (c)  y = f(x)

What do you expect the function signature of 'output_to' to be?  Is it 
callable?  Is it something that is going to be a stream wrapper, that 
has .read() and .write()?  Is it an intermediary, something that can be 
built as an object and bound between two streams bidirectionally?

     f().transform(x, y)

Another case, which would suffer from as much if not more API confusion, 
would be encrypting and decrypting...

     from Crypto.Cipher import DES

     obj = DES.new('abcdefgh', DES.ECB)
     plain = "Guido van Rossum is a space alien.XXXXXX"

In this case using .transform() would seem to be a good fit because 
there is no model, but 'obj' suffers from being directionless, so it 
becomes this...

     ciph = plain.transform(obj.encrypt)

...which isn't substantially clearer than...

     ciph = obj.encrypt(plain)

Parametric transformations don't bother me, but that would be an 
indication that there's a lot more going on, and perhaps there are 
better (and pre-existing) labels for these functions.


Joel