gh-112205: Support @getter annotation from AC#112396
Conversation
|
@AlexWaygood @erlend-aasland @colesbury This is the first draft version of getter annotation for AC. |
Co-authored-by: Alex Waygood <[email protected]>
Co-authored-by: Alex Waygood <[email protected]>
|
Now logic for clinic.py become straightforward. PTAL :) |
|
And I am going to implementer |
Tools/clinic/clinic.py
Outdated
| """) | ||
| 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.
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 <[email protected]>
|
@erlend-aasland @AlexWaygood |
colesbury
left a comment
There was a problem hiding this comment.
This looks great. I don't have any comments on top of what Erlend and Alex wrote.
AlexWaygood
left a comment
There was a problem hiding this comment.
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
| parser_code: list[str] | None | ||
| if not requires_defining_class: | ||
| if f.kind is GETTER: | ||
| flags = "NULL" |
There was a problem hiding this comment.
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.
Ah please ignore my previous comment, now I understood what you want to say :)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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.
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.
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.
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 :) |
Uh oh!
There was an error while loading. Please reload this page.