Skip to content
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

Merged
merged 18 commits into from
Nov 30, 2023
Merged

Conversation

corona10
Copy link
Member

@corona10 corona10 commented Nov 25, 2023

@corona10
Copy link
Member Author

corona10 commented Nov 25, 2023

@AlexWaygood @erlend-aasland @colesbury

This is the first draft version of getter annotation for AC.
Please leave some feedback for changes, and then I will add test code at the end.

Tools/clinic/clinic.py Outdated Show resolved Hide resolved
Tools/clinic/clinic.py Outdated Show resolved Hide resolved
corona10 and others added 2 commits November 25, 2023 20:58
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
Tools/clinic/clinic.py Outdated Show resolved Hide resolved
@corona10
Copy link
Member Author

corona10 commented Nov 25, 2023

Now logic for clinic.py become straightforward. PTAL :)

@corona10
Copy link
Member Author

And I am going to implementer @setter annotation with separate PR :)

@@ -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}},
Copy link
Member Author

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 :)

@erlend-aasland
Copy link
Contributor

Thanks, Donghee! Can you also create a docs PR for the devguide?

@corona10
Copy link
Member Author

corona10 commented Nov 27, 2023

Thanks, Donghee! Can you also create a docs PR for the devguide?

Sure, Do you have any recommended section for this?

Tools/clinic/clinic.py Outdated Show resolved Hide resolved
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
@corona10
Copy link
Member Author

@erlend-aasland @AlexWaygood
Here is the documentation PR: python/devguide#1232
For @setter, I will add it once the directive is implemented.

Tools/clinic/clinic.py Outdated Show resolved Hide resolved
Copy link
Contributor

@colesbury colesbury left a 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.

Copy link
Member

@AlexWaygood AlexWaygood left a 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 :)

@corona10
Copy link
Member Author

I will wait @erlend-aasland 1-2days :)

@@ -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"
Copy link
Contributor

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.

Suggested change
flags = "NULL"
flags = "0"
Suggested change
flags = "NULL"
flags = "" # This should end up unused

@AlexWaygood?

This comment was marked as resolved.

Copy link
Member Author

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 :)

Copy link
Member Author

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.

struct PyGetSetDef {
const char *name;
getter get;
setter set;
const char *doc;
void *closure;
};

Copy link
Contributor

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.

Copy link
Member Author

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dde933e
Remove unnecessary template :)

Copy link
Contributor

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).

Copy link
Member

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 :)

Copy link
Contributor

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 :)

@corona10
Copy link
Member Author

corona10 commented Nov 29, 2023

@erlend-aasland If the current status is enough to be merged, I will merge this PR at this weekend :)
cc @AlexWaygood @colesbury

@corona10 corona10 merged commit 7eeea13 into python:main Nov 30, 2023
34 checks passed
@corona10 corona10 deleted the gh-112205 branch November 30, 2023 10:40
aisk pushed a commit to aisk/cpython that referenced this pull request Feb 11, 2024
Glyphack pushed a commit to Glyphack/cpython that referenced this pull request Sep 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants