-0

I don't see how this makes us better-off. We typically use argument clinic on user facing APIs that need a signature object or that have some sort of efficiency gain. For iterator objects, there is almost no payoff.

@JelleZijlstra IMO, it makes tends to make the C code less readable (with the AC codes, having run a tool on every edit, breaking up the natural flow of the C code, and making it more difficult to see where the costs are because the input processing is in a separate file).

Putting all C code into the ArgumentClinic was never a goal. That seems to be have been a new, contagious, and made up meme. Significant AC work was done in the first few years. Almost everything that wasn't done was omitted on purpose because there was no payoff.

@rhettinger I agree that carpet conversion of METH_NOARGS/METH_Os brings little to no complexity benefit.

That's why I limit scope of changes to a very few small class declarations with unusual naming (here it vs self first method parameter and a private structure with full-fledged typedef).

Significant AC work was done in the first few years. Almost everything that wasn't done was omitted on purpose because there was no payoff.

Thanks for clarification. Initially I've thought that such functions were just missed because of a low priority or would use then-nonexistent AC features.

In this case this PR is the last one in the series (changed a part of to closes in the initial PR comment).

Thanks for explaining your thoughts. FWIW, there is no value in converting the it to self in the internal code and it is a step backwards from the norms (like we use so for setobject instances rather than self). Also, I believe it was decided (and don't remember when or why) to not sweep through and convert all the object structs to the .tp_name style. That is mostly being done for new ones. One further thought is that code churn like this creates it own new problems, making it difficult to backport fixes, and risking small API changes when applying AC (that has happened a few times).

I'm going to mark this one as closed. Thanks for the PR but I think we're better off without it. No user is going to benefit from this PR, it would just churn code that has been stable for a good while.

Please do keep contributing. Perhaps aims you time and skills at some of the 5,000 open issues where we know something needs to be fixed :-)