<div dir="ltr"><div>Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field.</div><div><br></div><div>Since the `co_extra` discussions do not affect CPython itself I'm planning on landing the changes stemming from the PEP probably on Monday.</div><div><br></div><div>----------</div><div><br></div><div>Expanding ``PyCodeObject``</div><div>--------------------------</div><div><br></div><div>One field is to be added to the ``PyCodeObject`` struct</div><div>[#pycodeobject]_::</div><div><br></div><div>  typedef struct {</div><div>     ...</div><div>     PyObject *co_extra;  /* "Scratch space" for the code object. */</div><div>  } PyCodeObject;</div><div><br></div><div>The ``co_extra`` will be ``NULL`` by default and will not be used by</div><div>CPython itself. Third-party code is free to use the field as desired.</div><div>Values stored in the field are expected to not be required in order</div><div>for the code object to function, allowing the loss of the data of the</div><div>field to be acceptable. The field will be freed like all other fields</div><div>on ``PyCodeObject`` during deallocation using ``Py_XDECREF()``.</div><div><br></div><div>Code using the field is expected to always store a tuple in the field.</div><div>This allows for multiple users of the field to not trample over each</div><div>other while being as performant as possible. Typical usage of the</div><div>field is expected to roughly follow the following pseudo-code::</div><div><br></div><div>  if co_extra is None:</div><div>    data = DataClass()</div><div>    co_extra = (data,)</div><div>  else:</div><div>    assert isinstance(co_extra, tuple)</div><div>    for x in co_extra:</div><div>        if isinstance(x, DataClass):</div><div>            data = x</div><div>            break</div><div>    else:</div><div>        data = DataClass()</div><div>        co_extra += (data,)</div><div><br></div><div>Using a list was considered but was found to be less performant, and</div><div>with a key use-case being JIT usage the performance consideration it</div><div>was deemed more important to use a tuple than a list. A tuple also</div><div>makes more sense semantically as the objects stored in the tuple will</div><div>be heterogeneous.</div><div><br></div><div>A dict was also considered, but once again performance was more</div><div>important. While a dict will have constant overhead in looking up</div><div>data, the overhead for the common case of a single object being stored</div><div>in the data structure leads to a tuple having better performance</div><div>characteristics (i.e. iterating a tuple of length 1 is faster than</div><div>the overhead of hashing and looking up an object in a dict).</div></div>