Here are some thoughts from the top of my head:
Currently, Argument Clinic produce normalised PyMethod_Def entries[^1]. We structure the parsed "function" data in Function and Parameter classes, and the C code generation is done via the CLanguage class. Recently, we also added support for getters and setters (PyGetSet_Def). Because of tp_init, tp_new and getters/setters, we now have a lot of special cases for all code that interacts with Function objects. Perhaps it is time to break up Function:
Function: responsibility of PyMethod_Def data
GetSet: responsibility of PyGetSet_Def data
Slot: responsibility for ... slots? Perhaps this is too broad...
We also may want to break up the code generation; output_templates and render_function has been refactor targets for a long time (they account for a very large percentage of clinic.py). @AlexWaygood and I did some small refactorings last year, and we've been trying out some ideas. One possibility, is to have multiple generator classes.
Here are some thoughts from the top of my head: Currently, Argument Clinic produce normalised
PyMethod_Defentries[^1]. We structure the parsed "function" data inFunctionandParameterclasses, and the C code generation is done via theCLanguageclass. Recently, we also added support for getters and setters (PyGetSet_Def). Because oftp_init,tp_newand getters/setters, we now have a lot of special cases for all code that interacts withFunctionobjects. Perhaps it is time to break up Function:We also may want to break up the code generation;
output_templatesandrender_functionhas been refactor targets for a long time (they account for a very large percentage of clinic.py). @AlexWaygood and I did some small refactorings last year, and we've been trying out some ideas. One possibility, is to have multiple generator classes.[^1]: except for
__init__and__new__slots