attributes of Python code objects
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 ? Xavier [1] https://github.com/python/cpython/pull/218 [2] https://docs.python.org/3/reference/datamodel.html [3] https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt
On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye <xdegaye@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. -Brett
Xavier
[1] https://github.com/python/cpython/pull/218 [2] https://docs.python.org/3/reference/datamodel.html [3] https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt _______________________________________________ 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/brett%40python.org
On 27 February 2017 at 06:44, Brett Cannon <brett@python.org> wrote:
On Sun, 26 Feb 2017 at 02:20 Xavier de Gaye <xdegaye@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@gmail.com | Brisbane, Australia
participants (3)
-
Brett Cannon -
Nick Coghlan -
Xavier de Gaye