[Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra (original) (raw)

Brett Cannon brett at python.org
Sat Sep 3 15:27:19 EDT 2016

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.

Since the co_extra discussions do not affect CPython itself I'm planning on landing the changes stemming from the PEP probably on Monday.

Expanding PyCodeObject

One field is to be added to the PyCodeObject struct [#pycodeobject]_::

typedef struct { ... PyObject co_extra; / "Scratch space" for the code object. */ } PyCodeObject;

The co_extra will be NULL by default and will not be used by CPython itself. Third-party code is free to use the field as desired. Values stored in the field are expected to not be required in order for the code object to function, allowing the loss of the data of the field to be acceptable. The field will be freed like all other fields on PyCodeObject during deallocation using Py_XDECREF().

Code using the field is expected to always store a tuple in the field. This allows for multiple users of the field to not trample over each other while being as performant as possible. Typical usage of the field is expected to roughly follow the following pseudo-code::

if co_extra is None: data = DataClass() co_extra = (data,) else: assert isinstance(co_extra, tuple) for x in co_extra: if isinstance(x, DataClass): data = x break else: data = DataClass() co_extra += (data,)

Using a list was considered but was found to be less performant, and with a key use-case being JIT usage the performance consideration it was deemed more important to use a tuple than a list. A tuple also makes more sense semantically as the objects stored in the tuple will be heterogeneous.

A dict was also considered, but once again performance was more important. While a dict will have constant overhead in looking up data, the overhead for the common case of a single object being stored in the data structure leads to a tuple having better performance characteristics (i.e. iterating a tuple of length 1 is faster than the overhead of hashing and looking up an object in a dict). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160903/37a79623/attachment.html>

More information about the Python-Dev mailing list