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 | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4