Walter Dörwald writes:
> Am 15.11.2013 um 00:42 schrieb Serhiy Storchaka <storch...@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).
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.
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.)
Footnotes:
[1] Arguments "decoder" and "codec" are identifiers, not metavariables.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
