[Python-Dev] Re: Optional arguments for str.encode /.decode
Walter Dörwald
walter at livinglogic.de
Fri Nov 7 14:10:18 EST 2003
Barry Warsaw wrote:
> On Fri, 2003-11-07 at 11:11, Tim Hochberg wrote:
>
>
>>The downside is that::
>>
>> s.encode(codec.zlib)
>>
>>wouldn't work. One would probably have to use the more verbose syntax::
>>
>> s.encode(codec.zlib())
>
>
> Maybe not. s.encode() can magically zero-arg instantiate the class.
> We're starting to put a lot of smarts into .encode() and .decode() but I
> think it's worth it. Nice idea.
Would this mean any changes to the C API? And if we're going to enhance
the C API, so that
PyObject *PyUnicode_Encode(
const Py_UNICODE *s,
int size,
const char *encoding,
const char *errors
);
becomes
PyObject *PyUnicode_Encode(
const Py_UNICODE *s,
int size,
PyObject *encoding,
const char *errors
);
would it make sense to enhance the PEP 293 error callback machinery
to allow
PyObject *PyUnicode_Encode(
const Py_UNICODE *s,
int size,
PyObject *encoding,
PyObject *errors
);
so that the callback function can be passed directly to the codec
without any need for registering/lookup?
Bye,
Walter Dörwald
More information about the Python-Dev
mailing list