-
-
Notifications
You must be signed in to change notification settings - Fork 31.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
bpo-36876: Moved Parser/listnode.c statics to interpreter state. #16328
Conversation
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.
mostly LGTM
I have left just a few small suggestions to consider.
/* | ||
* See bpo-36876: miscellaneous ad hoc statics have been moved here. | ||
*/ | ||
struct { |
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.
If you think there will be any other parser/compiler-related state to move to PyInterpreterState then consider making this struct stand-alone and perhaps even creating pycore_compiler.h (or pycore_parser.h) for it. That way the code doesn't get too cluttered.
Parser/listnode.c
Outdated
atbol = 1; | ||
PyInterpreterState *interp = _PyInterpreterState_GET_UNSAFE(); | ||
|
||
interp->parser_data.listnode_data.level = 0; |
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 was going to point to the advantage of having stand-alone structs for places like this (so there isn't so much going on with each line). However, I actually kind of like how the line captures the indirection clearly. :)
You can add listnode or parser variable to avoid having to write "interp->parser.listnode". But for that, you need to name the structure in pycore_pystate.h. |
I'm not quite sure what you mean. The change was specifically to move those variables into the interpreter state rather than stand-alone variables, as they were previously. |
I suggest to add |
Ah, OK, I understand now :-) Not sure what an additional variable buys in this case. I agree, if readability were adversely affected, it would be worth doing. As it is, it seems readable enough. |
It was just a minor remark for readability. You're free to ignore it ;-) |
https://bugs.python.org/issue36876