Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
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.
Why don't we put all string transformation functions into a common
module (the string module might be a good place):
import string
string.rot13('abc')
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
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
On 2007-06-19 14:40, Walter Dörwald wrote:
Georg Brandl wrote:
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 see much of a problem with that. Parameters are
per-se intended to change the behavior of a function or
method.
Note that you are referring to the .encode() and .decode()
methods - these are just easy to use interfaces to the codecs
registered in the system.
The codec design allows for different input and output
types as it doesn't impose restrictions on these. Codecs
are more general in that respect: they don't just deal
with Unicode encodings, it's a more general approach
that also works with other kinds of data types.
The access methods, OTOH, can impose restrictions and probably
should to restrict the return types to a predicable set.
Why don't we put all string transformation functions into a common
module (the string module might be a good place):
import string
string.rot13('abc')
I think the string module will have to go away. It doesn't
really separate between text and bytes data.
Adding more confusion will not really help with making
this distinction clear, either, I'm afraid.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 19 2007)
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2007-07-09: EuroPython 2007, Vilnius, Lithuania19 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
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
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:
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
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
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
___
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
Re: [Python-Dev] [Python-3000] Python 3000 Status Update (Long!)
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 ___ 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
