You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code emitted by the compiler, stored in PyCodeObject.co_code, and executed in the eval loop clearly has a well-defined format. In 2016 (bpo-26647) we switched to a fixed size wordcode (16 bits). There are a number of details about that format which aren't obvious, nor easy to discover (especially for someone new to the code).
Consequently, it would be helpful to have the format documented (in an easily discovered location). I haven't been able to find anything like that, other than a few scattered comments in the code (in relatively non-obvious places). We have similar documentation in .txt files in the Objects dir (e.g. dictnotes.txt). Something like that would make sense to me. Likewise we have comments with a similar utility in various source and header files (e.g. Objects/odictobject.c,). Another option might be to put it in the devguide, though it would probably be better to keep it in the repo, tied to the implementation it describes.
(FYI, this issue was born of discussion on one of my PRs.)
The text was updated successfully, but these errors were encountered:
The code emitted by the compiler, stored in
PyCodeObject.co_code
, and executed in the eval loop clearly has a well-defined format. In 2016 (bpo-26647) we switched to a fixed size wordcode (16 bits). There are a number of details about that format which aren't obvious, nor easy to discover (especially for someone new to the code).Consequently, it would be helpful to have the format documented (in an easily discovered location). I haven't been able to find anything like that, other than a few scattered comments in the code (in relatively non-obvious places). We have similar documentation in .txt files in the Objects dir (e.g. dictnotes.txt). Something like that would make sense to me. Likewise we have comments with a similar utility in various source and header files (e.g. Objects/odictobject.c,). Another option might be to put it in the devguide, though it would probably be better to keep it in the repo, tied to the implementation it describes.
(FYI, this issue was born of discussion on one of my PRs.)
The text was updated successfully, but these errors were encountered: