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
_______________________________________________
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
