2012/7/18 Nick Coghlan <ncoghlan at gmail.com>: > On the cpyext front, it would be rather helpful if developers interested in > a high speed Python interpreter with good C extension compatibility worked > with Dave Malcolm on his static analyser for Python C extensions. One of the > reasons cpyext has trouble is that many refcounting bugs in extensions > aren't fatal on CPython’s due to additional internal references - a refcount > of 1 when it should be 2 is survivable in a way that 0 vs 1 is not. It's not only about bugs. Even when reference counts are correctly managed, cpyext is slow: - each time an object crosses the C|pypy boundary, there is a dict lookup (!) - each time a new object is passed or returned to C, a PyObject structure must be allocated (and sometime much more, specially for strings and types). Py_DECREF will of course free the PyObject, so next time will allocate the object again. - borrowed references are a nightmare. > Get rid of that drudgery from hacking on cpyext and it becomes significantly > easier to expand the number of extensions that will work across multiple > implementations of the API. There are also some extension modules that play tricky games with the API; PyQt for example uses metaclasses with a custom tp_alloc slot, to have access to the PyTypeObject structure during the construction of the type... The Python C API is quite complete, but some use cases are still poorly supported. -- Amaury Forgeot d'Arc
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