[Python-Dev] attributes of Python code objects
Nick Coghlan
ncoghlan at gmail.com
Mon Feb 27 02:24:58 EST 2017
More information about the Python-Dev mailing list
Mon Feb 27 02:24:58 EST 2017
- Previous message (by thread): [Python-Dev] attributes of Python code objects
- Next message (by thread): [Python-Dev] GDB macros in Misc/gdbinit are broken
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 27 February 2017 at 06:44, Brett Cannon <brett at python.org> wrote: > > > On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye <xdegaye at gmail.com> wrote: > >> In PR 218 [1], INADA Naoki wrote: >> > I think attributes of Python's code object is implementation detail, >> even >> > though PyPy follows. >> > But it's not big problem until there are some Python implementation >> > having different code implementation. >> >> Python's code object attributes are described in the Data Model [2] >> section of >> the documentation. 1) Is this description normative (to be followed by >> all the >> implementations of the Python language)? 2) Is the description of >> co_lnotab >> in [3] normative ? >> > > That's a good question. "Code objects represent byte-compiled executable > Python code, or bytecode" which would suggest that if an implementation > didn't have a compiled code then code objects wouldn't make sense. Then > again the object contains details about the function that can be useful and > are relied upon by parts of the stdlib (e.g. inspect.signature() can't > function without the code object). > > Due to that last point I would say the attributes on code objects are not > an implementation detail, but it's acceptable for things like co_code to be > set to None when it doesn't make sense. > Right, we should probably try to be more explicit about this, as there are certainly aspects of the code object structure that other implementations will need to emulate if they want to re-use modules like inspect without modification. However, there are also aspects that we explicitly call out as implementation details, like the internal structure of co_code and co_lnotab, where they may change arbitrarily between CPython feature releases. The generator and coroutine ABCs were also specifically added so they could be replaced with objects that don't have __code__.co_flags attributes (e.g. by Cython) without breaking asyncio. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170227/2e0440ca/attachment.html>
- Previous message (by thread): [Python-Dev] attributes of Python code objects
- Next message (by thread): [Python-Dev] GDB macros in Misc/gdbinit are broken
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list