[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Aug 31 00:30:00 EDT 2016

On 31 August 2016 at 04:55, Serhiy Storchaka <storchaka at gmail.com> wrote:

On 30.08.16 21:20, Antoine Pitrou wrote:

But the performance overhead of iterating over a 1-element list is small enough (it's just an array access after a pointer dereference) that it may not be larger than the overhead of the multiple tests and conditional branches your example shows. Iterating over a tuple is even faster. It needs one pointer dereference less.

That comes at the cost of making metadata additions a bit more complicated though - you'd have to replace the existing tuple with a new one that adds your own metadata, rather than just appending to a list.

I do think there are enough subtleties here (going from no metadata -> some metadata, and some metadata -> more metadata) that it makes sense to provide a standard API for it (excluded from the stable ABI), rather than expecting plugin developers to roll their own.

Strawman:

PyObject * PyCode_GetExtra(PyCodeObject *code, PyTypeObject *extra_type);
int PyCode_SetExtra(PyCodeObject *code, PyObject *extra);
int PyCode_DelExtra(PyCodeObject *code, PyTypeObject *extra_type);

Then Brett's example code would become:

pyjion_cache = PyCode_GetExtra(code_obj, &PyPyjion_Type);
if (pyjion_cache == NULL) {
    pyjion_cache = PyPyjion_New();
    if (PyCode_SetExtra(code_obj, pyjion_cache) < 0) {
        /* Something went wrong, report that somehow */        }
}
/* pyjion_cache is valid here */

Making those APIs fast (for an assumed small number of simultaneously active interpreter plugins) and thread-safe is then an internal CPython implementation detail, rather than being something plugin writers need to concern themselves with.

Cheers, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list