-
-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-112205: Support @getter annotation from AC #112396
Conversation
corona10
commented
Nov 25, 2023
•
edited by bedevere-app
bot
Loading
edited by bedevere-app
bot
- Issue: Support getters and setters in Argument Clinic #112205
@AlexWaygood @erlend-aasland @colesbury This is the first draft version of getter annotation for AC. |
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Now logic for clinic.py become straightforward. PTAL :) |
And I am going to implementer |
Tools/clinic/clinic.py
Outdated
@@ -865,6 +869,10 @@ class CLanguage(Language): | |||
#define {methoddef_name} \ | |||
{{"{name}", {methoddef_cast}{c_basename}{methoddef_cast_end}, {methoddef_flags}, {c_basename}__doc__}}, | |||
""") | |||
GETTERDEF_PROTOTYPE_DEFINE: Final[str] = normalize_snippet(r""" | |||
#define {methoddef_name} \ | |||
{{"{name}", {methoddef_cast}{c_basename}{methoddef_cast_end}, NULL, NULL}}, |
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.
We may need to reform the template for the setter case too. But not sure we should handle this at this PR :)
Thanks, Donghee! Can you also create a docs PR for the devguide? |
Sure, Do you have any recommended section for this? |
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@erlend-aasland @AlexWaygood |
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.
This looks great. I don't have any comments on top of what Erlend and Alex wrote.
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.
The Python code LGTM, thanks! As always, I'll leave review of the generated C code to the other two :)
I will wait @erlend-aasland 1-2days :) |
Tools/clinic/clinic.py
Outdated
@@ -1217,7 +1228,11 @@ def parser_body( | |||
parsearg: str | None | |||
if not parameters: | |||
parser_code: list[str] | None | |||
if not requires_defining_class: | |||
if f.kind is GETTER: | |||
flags = "NULL" |
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.
This looks strange to me; AFAICS, we don't use flags
for getters (methoddef_flags
is not included in the template). And if we were to supply a zero default for flags, it would have to be an int literal (0
, not NULL
).
Ideally we should not have to specify flags
here, but a lot of the following code expect it to be defined. I suggest we either set it to the empty string or the zero int literal.
flags = "NULL" | |
flags = "0" |
flags = "NULL" | |
flags = "" # This should end up unused |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
Ah please ignore my previous comment, now I understood what you want to say :)
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.
You may already know: the reason I don't use methodef_flags
to the template is due to the structure of getset
.
Lines 11 to 17 in a194938
struct PyGetSetDef { | |
const char *name; | |
getter get; | |
setter set; | |
const char *doc; | |
void *closure; | |
}; |
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.
We're not creating a PyMethodDef
struct here, so the template field naming is now confusing. For example, the methoddef_name
and methoddef_cast
names are just confusing when we're generating a PyGetSetDef
struct. I think we should fix the naming sooner than later.
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.
We're not creating a PyMethodDef struct here, so the template field naming is now confusing. For example, the methoddef_name and methoddef_cast names are just confusing when we're generating a PyGetSetDef struct. I think we should fix the naming sooner than later.
We need to refactor some of the code while implementing @setter
, Can we handle this issue on the @setter
PR? or Do you want to handle it as this PR?
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.
dde933e
Remove unnecessary template :)
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'm not sure my suggested comment is good enough :) Wording it more explicit might be better (cc. @AlexWaygood).
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 think this is fine... or, at least, I can't think of anything better :)
Looking at this function gives me a headache; this change doesn't really make my head hurt significantly more tbh :)
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.
Yes, the urge to refactor is growing. I suggest we take a stab at it pretty soon, Alex :)
@erlend-aasland If the current status is enough to be merged, I will merge this PR at this weekend :) |