M.-A. Lemburg schrieb:
On 2008-05-09 18:06, Guido van Rossum wrote:
On Fri, May 9, 2008 at 3:54 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
On 2008-05-08 22:55, Terry Reedy wrote:
Functions that map unicode->unicode or bytes->bytes could be called
transcoders. Each type could be given a .transcode method to go along with
but contrast with .encode or .decode.
Are you suggesting to have two separate methods which then
allow same-type-conversions ? One for encoding to the same
type and one for decoding ?
Fine with me.
They do have to map naturally to the codec method encode and
decode, though, so a single method won't do, unless maybe
you add a parameter to define the direction of the coding
process.
In summary, I'd just like to see the following happen:
* revert the type restrictions on the PyCodec_* API
* enforce the restrictions on the .encode() and .decode()
methods of PyUnicode and PyString objects (str and bytes)
* add a way to PyUnicode and PyString objects (str and bytes)
to allow same type encoding and decoding
+1
Will this get use the hex, base64 etc. "codecs" back? If yes, great!
Fine, so we need new methods for PyUnicode and PyString objects
which allow encoding and decoding using the same type (and enforce
the return types).
Any suggestions ?
How about these:
str.str_encode() -> str
str.str_decode() -> str
bytes.bytes_encode() -> bytes
bytes.bytes_decode() -> bytes
Cool, a naming contest :)
What about transform/untransform?
Georg
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
