Repository navigation
Argument Clinic: Better internal implementation for @getter and @setter #113318
Description
Activity
See also: #113160 (comment)
Thanks for creating this issue, Donghee. See #112205 (comment) for more info.
Reacted by Donghee NaNot only internal implementation needs improvement, but the interface too.
- Getter should support return converter.
- Setter should support converter for the single parameter (for example, ssl.SSLContext.options would benefit from this).
- Support deleter.
My 2c:
-
aliases aren't supported properly
-
"ifdef trick" doesn't work with get/setters. Trying to create a getter/setter in
#ifdefblock, I get following error from the clinic.py:
Traceback (most recent call last): File "/home/sk/src/cpython/Tools/clinic/clinic.py", line 11, in <module> main() ~~~~^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/cli.py", line 226, in main run_clinic(parser, args) ~~~~~~~~~~^^^^^^^^^^^^^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/cli.py", line 218, in run_clinic parse_file(filename, output=ns.output, ~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^ verify=not ns.force, limited_capi=ns.limited_capi) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/cli.py", line 84, in parse_file cooked = clinic.parse(raw) File "/home/sk/src/cpython/Tools/clinic/libclinic/app.py", line 193, in parse parser.parse(block) ~~~~~~~~~~~~^^^^^^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/dsl_parser.py", line 492, in parse block.output.extend(self.clinic.language.render(self.clinic, block.signatures)) ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/clanguage.py", line 83, in render return self.render_function(clinic, function) ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^ File "/home/sk/src/cpython/Tools/clinic/libclinic/clanguage.py", line 521, in render_function s = template.format_map(template_dict) KeyError: 'methoddef_name'-
#155778 fixes several bugs. A larger feature PR will follow.
- added 3 commits that reference this issue
on Aug 18, 2026 Thank you, and sorry for the delay reviewing. The rework looks too big to backport, but, that's done now.
Are you planning to update the documentation in the devguide?
It was a small bugfix. I have a larger feature branch on my hands, in process of polishing.
Documentation: python/devguide#1886.
#156066 is a feature PR. It changes how properties are implemented internally and how the code is generated. It also adds support of input and output converters.
I have also a follow-up which adds support of separate
@deleter, but it adds quite complexity, and currently there is no need of such feature. So I will hold it until there was a real need.python/devguide#1887 is the documentation part.
Reacted by Sergey B KirpichevReacted by Petr ViktorinAs I noted on the docs PR, I'm concerned about using a "default value" as placeholder for
del. From:/*[clinic input] @critical_section @setter @deleter MyType.count value: int = -1 [clinic start generated code]*/it is not obvious that the
-1is what's used when deleting. I fear that this is replacing one footgun with another (though a much smaller one of course).I'd be interested in the separate deleter functions. Could we use that when converters are needed? I guess the
NULLfor pointers is needed for backcompat/familiarity, but it seems really awkward for other types.I don't want to encourage things like making
obj.count = -1equivalent todel obj.count.See also #156106 which adds tests for all writable attributes.
Added restriction: only NULL is allowed as default value for setter-and-deleter. This restriction is artificial, it does not simplify the code. For now, there are no properties with converters which do not accept NULL as default value, so the issue is rather hypothetical.
I can publish a PR for the separate deleter functions after merging #156066. It adds complexity without any benefits for current code, so I do not recommend to accept it now.
Most of the current deleters raise TypeError. If we accept AttributeError instead, we can remove these deleters -- only 6 will remain. And we can then deprecate these 6 -- they do nothing that the setter cannot do.
Reacted by Petr Viktorin
Even though we successed to provide
@getterand@setterfeatures from #112205The current internal implementation is full of hacky workaround.
We need to improve the internal implementation for better generated C codes and maintenance.
@erlend-aasland wrote some ideas for this: #112205 (comment)
Linked PRs