2012/7/18 Nick Coghlan <[email protected]>: > 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 _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
