Out of curiosity, what is the reason for leaving this condition to the preprocessor iso. just outputting the two blocks (keywords == 0, keywords != 0) conditionally from AC? I've probably overlooked some scenario here :)

I found it made it easier to identify what was going on. However, that might not be as valuable now that I've ironed out the kinks and the change is working well. I'll see what it looks like with the unnecessary condition removed.

Now I remember... clinic.py works by building a template for generating code and then applying values to that template in a later step. The code to which you referred is part of that generation step. We don't have the actual num_keywords value at that point, so we generate all the cases. It isn't great but we'd have to (almost) completely re-write clinic.py if we wanted to do this in a simpler way. 🙁

Ah, yes, I remember this from an earlier issue or PR. Perhaps we should leave a comment in there in case such a restructuring/rewrite happens in the future?

Looking at this again, it should be possible to deduce num_keywords during the template generation. We've got the Function object f, which contains the parameters dict. Each value in the dict is a Parameter object, which contains the information needed to tell if a parameter can be a keyword parameter or not.

I'll submit a PR against your fork with a proof-of-concept.

The situation is inherent to the clinic.py implementation, so a comment here feels out of place. If anything, it would make sense to add some in-tree documentation about the implementation: either a long docstring at the top of clinic.py or an adjacent README. However, that would happen in a separate PR.

Regarding adding a comment: agreed.

Regarding my suggestion of calculating num_keywords during template generation, in order to generate nicer AC output: see gh-95907