Repository navigation
Generate opcode metadata from bytecodes.c instead of opcode.py #105481
Description
Activity
- added 5 commits that reference this issue
on Jun 8, 2023 - added a commit that references this issue
on Jun 14, 2023 @gvanrossum The old macros HAS_ARG and HAS_CONST are exposed in Include/opcode.h (and have been for a long time). Does this mean that before we can remove them, we need to expose the opcode_metadata.h file there as well? We should also mark all of this as unstable API (how do we do that?)
- added a commit that references this issue
on Jun 15, 2023 Neither
HAS_ARGnorHAS_CONSTis mentioned in the docs at all. I am of the opinion that in this case this implies they are not public, and anyone using them should not be surprised if they disappear. (It would be more of an issue if they turned into lies.)opcode.h is mentioned only once in the docs, as the source of truth for dis.py. (It is also mentioned twice in Misc/NEWS.d/, but that's really just a changelog.)
I do think we ought to provide similar functionality to debuggers.
Info about declaring unstable APIs comes from PEP 649, which links to https://devguide.python.org/developer-workflow/c-api/#c-api. It looks like you must use the
PyUnstable_prefix (e.g.PyUnstable_BytecodeHasArg), and it ought to be in a .h file under Include/cpython/.I do think we ought to provide similar functionality to debuggers.
Do you mean to expose the stuff in opcode_metadata.h file through some unstable c api?
Yeah, to the extent that it’s useful, in function form (so the data structure is not public).
Or we can wait until someone asks.
32 remaining items
- added 8 commits that reference this issue
on Aug 14, 2023 - added a commit that references this issue
on Aug 23, 2023 I'm not sure it was the right move to rename
_PyUnstable_GetUnaryIntrinsicNametoPyUnstable_GetUnaryIntrinsicName, etc.I created them as private because I did not intend to document them as a public API (we need a reason to do that). I put Unstable in the name because it's one of those things that can change all the time. If we don't want the
_PyUnstable_prefix then let's remove theUnstableand leave the_until we have a reason/decision to make these part of the public C API.
We would ideally have bytecodes.c as the single source of truth about opcodes. So opcode.py and the code generated from it should be replaced by alternatives from the cases_generator, if we can.
Linked PRs