[Python-Dev] Add transform() and untranform() methods

[Walter Dörwald]

Am 15.11.2013 um 16:57 schrieb "Stephen J. Turnbull" <stephen at xemacs.org>:
> 
> Walter Dörwald writes:
>>> Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka <storchaka at gmail.com>:
>>> 
>>> 15.11.13 00:32, Victor Stinner написав(ла):
>>>> And add transform() and untransform() methods to bytes and str types.
>>>> In practice, it might be same codecs registry for all codecs just with
>>>> a new attribute.
>>> 
>>> If the transform() method will be added, I prefer to have only
>>> one transformation method and specify a direction by the
>>> transformation name ("bzip2"/"unbzip2").
>> 
>> +1
> 
> -1
> 
> I can't support adding such methods (and that's why I ended up giving
> Nick's proposal for exposing codecs.encode and codecs.decode a +1).

My +1 was only for having the transformation be one-way under the condition that it is added at all.

> People think about these transformations as "en- or de-coding", not
> "transforming", most of the time.  Even for a transformation that is
> an involution (eg, rot13), people have an very clear idea of what's
> encoded and what's not, and they are going to prefer the names
> "encode" and "decode" for these (generic) operations in many cases.
> 
> Eg, I don't think "s.transform(decoder)" is an improvement over
> "decode(s, codec)" (but tastes vary).[1]  It does mean that we need
> to add a redundant method, and I don't really see an advantage to it.

Actually my preferred method would be codec.decode(s). codec being the module that implements the functionality.

I don't think we need to invent another function registry.

> The semantics seem slightly off to me, since the purpose of the
> operation is to create a new object, not transform the original
> in-place.

This would mean the method would have to be called transformed()?

>  (But of course str.encode and bytes.decode are precedents
> for those semantics.)
> 
> 
> Footnotes: 
> [1]  Arguments "decoder" and "codec" are identifiers, not metavariables.

Servus,
   Walter