[Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs (original) (raw)

Walter Dörwald walter at livinglogic.de
Thu Jun 10 12:30:01 CEST 2010

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.

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).

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.

[...]

Servus, Walter

More information about the Python-Dev mailing list