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

Brett Cannon brett at python.org
Mon Aug 29 19:14:23 EDT 2016

On Mon, 29 Aug 2016 at 15:51 Guido van Rossum <guido at python.org> wrote:

Anyway, given the outcome of Dino's tests I have no objections to the PEP. (Though using Christian's hack would be cool.)

Great! I'll mark the PEP as accepted and get the implementation in for 3.6.

On Mon, Aug 29, 2016 at 3:28 PM, Christian Heimes <christian at python.org> wrote: > On 2016-08-29 23:38, Brett Cannon wrote: >> That means we still want to find a solution to attach arbitrary data to >> code objects without sacrificing performance. One proposal is what's in >> PEP 523 for the extra field. Another option is to make the memory >> allocator for code objects pluggable and introduce a new flag that >> signals that the object was created using a non-default allocator. >> Obviously we prefer the former solution due to its simplicity. :) > > May I remind you that you can have the field with no extra memory cost? > :)

Yes you may. :)

The struct has sub-par alignments.

So the struct in question can be found at https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Include/code.h#L10 . The official docs say the fields can be changed at any time, so re-arranging them shouldn't break any ABI compatibility promises: https://docs.python.org/3/c-api/code.html#c.PyCodeObject . Would grouping all the fields of the same type together, sorting them by individual field size (i.e. PyObject*, void*, int, unsigned char*), and then adding the co_extra field at the end of the grouping of PyObject * fields do what you're suggesting? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160829/1efb8a7b/attachment.html>

More information about the Python-Dev mailing list