Georg Brandl wrote:
Walter Dörwald schrieb:
Georg Brandl wrote:
Nick Coghlan schrieb:
Georg Brandl wrote:
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
Guido van Rossum schrieb: 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