RetroSearch Browse

Fri Nov 7 14:10:18 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040085.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040085.html below:

[Python-Dev] Re: Optional arguments for str.encode /.decode