I disagree that the Clinic DSL is "verbose".  Certainly I find it
more succinct than what we do now.

On the other hand, the syntax you proposed in the python-dev message
you cite is insufficient to the task.  Consider a function that
takes a "char *".  How might you want Python to convert the Python
value into that char *?  Should it only accept bytes?  Should it
accept bytes and Unicode?  Should it accept objects exposing the
buffer protocol?  Do you want the length too?  If you want the
length, does that mean that you accept nulls inside the string?
If it's Unicode, do you want to use a default encoding, or do you
want to specify an encoding?  Or do you want to specify your own
conversion function?

My solution for the above is to add "flags".  Which is,
semantically, the only important distinction between what you
propose and Clinic's DSL.  (That and the per-argument docstrings,
which I already suggest are negotiable.)  The remaining differences
are that you want to cram everything onto one line, wheras Clinic's
DSL spreads things over multiple lines.  I suggest the latter is
more readable, particularly when the number of arguments grows
large.

To answer 5), you're the only C contributor who comes to mind who
seems unhappy.  Do I understand you correctly that your main pain
point is that you generate scores of identical functions with the
C preprocessor, and you see no way to do that with Clinic?  If we
figured out a way to make that work with Clinic, would that reduce
your concerns?