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

[M.-A. Lemburg]

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, Lithuania            19 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