Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32k
gh-105481: opcode.h is no longer generated during the build#108080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Uh oh!
There was an error while loading.Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LG, though I'm unsure of the benefit here. We now have two places where the list of NB_ constants occurs, once in opcode.h, once in _opcode.c, and they must be kept in sync manually.
@@ -36,6 +34,7 @@ extern "C" { | |||
#define NB_INPLACE_TRUE_DIVIDE 24 | |||
#define NB_INPLACE_XOR 25 | |||
#define NB_OPARG_LAST 25 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I dislike marking the "last" of anything, you end up doing+ 1
in various places. But I realize that it's a convention around opcode definitions and the like.
There are a number of lists/enumerations that need to exist in parallel python and C. I think to avoid the duplication in the code we should design something generic that spawns the #definitions in C and a function that builds the python dict to map the name to the number. Something like argument clinic, but for enumerations. I don't like having a special script for each case. |
Uh oh!
There was an error while loading.Please reload this page.
Python's operators don't change very often. This doesn't need to be auto-generated.