Repository navigation
Code objects, function objects and generator object contain quite a lot of redundant information #100719
Description
Activity
I have no opinion on whether these changes are good or bad, but they are surely breaking changes. Code objects aren't well documented, but they're not private implementation details. How do you plan to manage these changes?
The
PyCodeObjectstruct is in theInclude/cpythonfolder. So while it is not entirely private, we are allowed to change it.- added a commit that references this issue
on Jan 4, 2023 - added a commit that references this issue
on Feb 23, 2023 @stevendaprano The python-level doc for 'internal types', including code objects, https://docs.python.org/3/reference/datamodel.html#codeobject says
Their definitions may change with future versions of the interpreter, but they are mentioned here for completeness.
'co_nplaincellvars' is not even mentioned in the 3.11 docs.
generator objects are not listed here and their internal gi_xxx methods, as opposed to
__next__, send, and throw, are not indexed.
There is a quite a lot of redundancy in code, function and generator objects.
Intra-object redundancy
co_nlocalsplus,co_nplaincellvars,co_nlocals,co_nfreevars. Any of these fields can be computed from the other three.gi_codefield, which is redundant, as the frame contains a reference to the code object.Inter-object redundancy
Linked PRs
co_nplaincellvarsfield from code objects. #100721gi_codefield from generator object. #100749