A RetroSearch Logo

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

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2011-February/107960.html below:

[Python-Dev] API bloat

[Python-Dev] API bloatMark Shannon marks at dcs.gla.ac.uk
Wed Feb 9 13:11:43 CET 2011
M.-A. Lemburg wrote:
> Mark Shannon wrote:
>> The Unicode Exception Objects section is new and seemingly redundant:
>> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
>> Should this be in the public API?
> 
> Those function have been in the public API since we introduced
> Unicode callbak error handlers.
> 
> It was an oversight that these were not documented in the Python
> documentation. They have been documented part of the unicodeobject.h
> ever since they were introduced.
> 
> Note that these APIs are needed by codecs supporting the
> callback error handlers, and since performance matters a lot
> for codecs, the C APIs were introduced.
> 

OK, so UnicodeError_xxx is important for codecs, but surely this sort of 
argument could be made for lots of things.
Don't forget that for each function added to the API,
all other implementations have to support it forever.

Unfortunately, UnicodeError_xxx are not the only new functions.

Various others have been added:

int Py_EnterRecursiveCall(char *where)
void Py_LeaveRecursiveCall()
int Py_ReprEnter(PyObject *object)
void Py_ReprLeave(PyObject *object)

HotPyModule_GetFilenameObject
HotPy_CompileStringExFlags

and a few others.

Individual functions are not the problem,
I'm sure all of these can be justified,
its lack of process and review that bothers me.

Mark.
More information about the Python-Dev mailing list

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