Support getters and setters in Argument Clinic

[colesbury]

Feature or enhancement

In the C API, getters and setters are implemented using PyGetSetDef. Argument Clinic doesn't currently support writing getters and setters, probably because they are pretty straightforward to write manually -- there's not much argument parsing to be done.

Argument Clinic now supports the @critical_section directive, which avoids a bunch of boilerplate code when making things thread-safe with the --disable-gil builds. It would be helpful if Argument Clinic supported getters/setters so that we could avoid the critical section boilerplate in getters and setters as well.

Linked PRs

• gh-112205: Support @getter annotation from AC #112396
• gh-112205: Update stringio module to use AC for the thread-safe #112549
• gh-112205: Support @setter annotation from AC #112922
• gh-112205: Update textio module to use @getter as possible. #113095
• gh-112205: Support docstring for @getter #113160
• gh-112205: Require @getter and @setter to be methods #113278

[colesbury]

cc @aisk (who brought up this issue in #112116 (comment)) and @erlend-aasland for feedback

[corona10]

Another example that needs this feature: #112298

[corona10]

@colesbury @erlend-aasland @AlexWaygood
(Just for example)
What about following DSL for name setter / getter case?
It looks similar to Java lombok annotation :(

/*[clinic input] 
@setter
@getter
@critical_section
_io._Buffered.name
[clinic start generated code]*/

[corona10]

/*[clinic input] 
@getter
@critical_section
_io._Buffered.name
[clinic start generated code]*/

/*[clinic input] 
@setter
@critical_section
_io._Buffered.name
[clinic start generated code]*/

I am working on supporting @setterwith the co-existence case of @getter.
Separating clinic input is more straightforward and cleaner than declaring with a single input.

[AlexWaygood]

Separating clinic input is more straightforward and cleaner than declaring with a single input.

I think it looks nicer as well — having the three stacked decorators kinda looked ugly to me. Moreover, the slightly more verbose syntax of having the two inputs separated is closer to how you'd implement a Python property with a setter. In short: good choice, IMO :-)

[erlend-aasland]

Following up discussions on #113160.

See my comments for context:

• gh-112205: Support docstring for @getter #113160 (comment)
• gh-112205: Support docstring for @getter #113160 (comment)

Here's a quick braindump of how I'd like the PyGetSetDef feature to be handled internally in Argument Clinic:

• PyGetSetDef belongs to a type object, implying it needs to be paired with a class directive in the current clinic scope (file scope). We can put this guard (a fail(...)) at the end of the "state-modulename-name" stage of the parsing state machine.
• The PyGetSetDef metadata (getter, setter, docstr, ...) could (should) be stored on the Class where the PyGetSetDef belongs; Class already has a functions member; perhaps we can use this. My first thought is to add a render() method to Class, and call this somewhere in the generation phase. This render() method could introspect its getters and setters (for example via self.functions), and produce the #define that will end up being used in the actual PyGetSetDef definition. We should end up with cleaner templates, cleaner generated code, and more maintainable clinic.py code.
• The Function objects [for getters and setters] should not hack around with the PyMemberDef template stuff; it should only deal with the templates for the C function declarations.

I think the clinic input side of things work well! My complaints are strictly about clinic internals :)

[corona10]

I think the clinic input side of things work well! My complaints are strictly about clinic internals :)

Yeah, I fully agree with your suggestion. The current hacky implementation is a kind of tech debt.
With refactoring, it will generate better C code. (and as I commented, I fully agree that it will need to be improved)
If you don't mind, can we create a new issue as the improving issue? I think that we agree that the design of input is acceptable.
I prefer to close this issue when the #113160 is merged as marking the completion of first phase of this feature :)

[erlend-aasland]

If you don't mind, can we create a new issue as the improving issue? I think that we agree that the design of input is acceptable. I prefer to close this issue when the #113160 is merged as marking the completion of first phase of this feature :)

Yes, see what I wrote in #113160 (comment) ;)

[corona10]

I created a follow-up issue and am now closing the current issue.: #113318

Thank you for all your support @colesbury @erlend-aasland @AlexWaygood and @vstinner