[Python-Dev] Add transform() and untranform() methods
Stephen J. Turnbull
stephen at xemacs.org
Fri Nov 15 16:57:00 CET 2013
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).
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.
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. (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