[Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs

M.-A. Lemburg mal at egenix.com
Thu Jun 10 13:08:26 CEST 2010


Walter Dörwald wrote:
> On 09.06.10 14:47, Nick Coghlan wrote:
> 
>> On 09/06/10 22:18, Victor Stinner wrote:
>>> Le mercredi 09 juin 2010 10:41:29, M.-A. Lemburg a écrit :
>>>> No, .transform() and .untransform() will be interface to same-type
>>>> codecs, i.e. ones that convert bytes to bytes or str to str. As with
>>>> .encode()/.decode() these helper methods also implement type safety
>>>> of the return type.
>>>
>>> What about buffer compatible objects like array.array(), memoryview(), etc.?
>>> Should we use codecs.encode() / codecs.decode() for these types?
>>
>> There are probably enough subtleties that this is all worth specifying 
>> in a PEP:
>>
>> - which codecs from 2.x are to be restored
>> - the domain each codec operates in (binary data or text)*
>> - review behaviour of codecs.encode and codecs.decode
>> - behaviour of the new str, bytes and bytearray (un)transform methods
>> - whether to add helper methods for reverse codecs (like base64)
>>
>> The PEP would also serve as a reference back to both this discussion and 
>> the previous one (which was long enough ago that I've forgotten most of it).
> 
> I too think that a PEP is required here.

Fair enough. I'll write a PEP.

> Codecs support several types of error handling that don't make sense for
> transform()/untransform(). What should 'abc'.decode('hex', 'replace')
> do? (In 2.6 it raises an assertion error, because errors *must* be strict).

That's not really an issue since codecs don't have to implement
all error handling schemes.

For starters, they will all only implement 'strict' mode.

> I think we should takt this opportunity to implement
> transform/untransform without being burdened with features we inherited
> from codecs which don't make sense for transform/untransform.

Not sure what you mean here. Those methods are just helper methods
which interface to the codec system and provide return type safety.
Nothing more or less.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 10 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                38 days to go

::: Try our new mxODBC.Connect Python Database Interface 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
               http://www.egenix.com/company/contact/


More information about the Python-Dev mailing list