[Python-Dev] [Python-3000] Python 3000 Status Update (Long!)

Walter Dörwald walter at livinglogic.de
Tue Jun 19 16:45:46 CEST 2007

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:


compared to:


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.


More information about the Python-Dev mailing list