Georg Brandl wrote:
> Walter Dörwald schrieb:
>> Georg Brandl wrote:
>>> Nick Coghlan schrieb:
>>>> Georg Brandl wrote:
>>>>> Guido van Rossum schrieb:
>>>>>> I've written up a comprehensive status report on Python 3000. Please
>>>>>> read:
>>>>>>
>>>>>> http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>>>>> Thank you! Now I have something to show to interested people except "read
>>>>> the PEPs".
>>>>>
>>>>> A minuscule nit: the rot13 codec has no library equivalent, so it won't be
>>>>> supported anymore :)
>>>> Given that there are valid use cases for bytes-to-bytes translations,
>>>> and a common API for them would be nice, does it make sense to have an
>>>> additional category of codec that is invoked via specific recoding
>>>> methods on bytes objects? For example:
>>>>
>>>> encoded = data.encode_bytes('bz2')
>>>> decoded = encoded.decode_bytes('bz2')
>>>> assert data == decoded
>>> This is exactly what I proposed a while before under the name
>>> bytes.transform().
>>>
>>> IMO it would make a common use pattern much more convenient and
>>> should be given thought.
>>>
>>> If a PEP is called for, I'd be happy to at least co-author it.
>> Codecs are a major exception to Guido's law: Never have a parameter
>> whose value switches between completely unrelated algorithms.
>
> I don't think that applies here. This is more like __import__():
> depending on the first parameter, completely different things can happen.
> Yes, the same import algorithm is used, but in the case of
> bytes.encode_bytes, the same algorithm is used to find and execute the
> codec.
What would a registry of tranformation algorithms buy us compared to a
module with transformation functions?
The function version is shorter:
transform.rot13('foo')
compared to:
'foo'.transform('rot13')
If each transformation has its own function, these functions can have
their own arguments, e.g.
transform.bz2encode(data: bytes, level: int=6) -> bytes
Of course str.transform() could pass along all arguments to the
registered function, but that's worse from a documentation viewpoint,
because the real signature is hidden deep in the registry.
Servus,
Walter
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
