Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
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
Walter Dörwald schrieb:
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?
Easier registering of custom transformations. Without a registry, you'd have to monkey-patch a module.
The function version is shorter:
transform.rot13('foo')
compared to:
'foo'.transform('rot13')
Yes, that's a very convincing argument :)
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.
I don't think transformation functions need arguments. Georg
What would a registry of tranformation algorithms buy us compared to a module with transformation functions?
Easier registering of custom transformations. Without a registry, you'd have to monkey-patch a module.
Or users would have to invoke the module directly. I think a convention would be enough: rot13.encode(foo) rot13.decode(bar) Then, "registration" would require to put the module on sys.path, which it would for any other kind of registry as well. My main objection to using an encoding is that for these, the algorithm name will *always* be a string literal, completely unlike "real" codecs, where the encoding name often comes from the environment (either from the process environment, or from some kind of input). Regards, Martin
participants (3)
-
"Martin v. Löwis" -
Georg Brandl -
Walter Dörwald