On Mon, 29 Aug 2016 at 15:51 Guido van Rossum <gu...@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 <christ...@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?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
