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.
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