On 09/02/2011 14:00, Benjamin Peterson wrote: > 2011/2/9 Mark Shannon<marks at dcs.gla.ac.uk>: >> 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. > The C-API is about the biggest implementation detail of CPython, so > no, they don't have to. > Alternative implementations that want C extensions to work (like Ironclad for IronPython and cpyext for pypy) do implement the parts of the C API that are most widely used though. Of course they don't *have to*, but c extension compatibility is one of the biggest problems for users of alternative implementations. Hopefully the stable ABI will improve this situation for the future, but realistically its going to be a few years before it has an appreciable effect. Michael >> 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. > > If they can be justified, what is the process lacking? > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
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