[Python-Dev] Add transform() and untranform() methods
walter at livinglogic.de
Fri Nov 15 21:00:50 CET 2013
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").
> 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). 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
This would mean the method would have to be called transformed()?
> (But of course str.encode and bytes.decode are precedents
> for those semantics.)
>  Arguments "decoder" and "codec" are identifiers, not metavariables.
More information about the Python-Dev