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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4