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

Walter Dörwald 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"). +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

More information about the Python-Dev mailing list