Am 15.11.2013 um 16:57 schrieb "Stephen J. Turnbull" <step...@xemacs.org>:
>
> 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).
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
_______________________________________________
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
