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).
*Some are obvious, such as rot13 being text only, and bz2 being binary
data only, but others are less clear. hex could be either str->str or
bytes->bytes, since ''.join(map(chr, seq)) and b''.join(map(ord, seq))
allow each of them to be implemented trivially in terms of the other. As
Antoine pointed out, base64 is really a reverse codec (encode from
bytes->str, decode from str->bytes), so it still wouldn't be covered by
the new transformation helper methods.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
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
