[Python-Dev] Announcing PEP 436: The Argument Clinic DSL

Terry Reedy tjreedy at udel.edu
Tue Feb 26 17:11:12 CET 2013

On 2/25/2013 7:11 PM, Larry Hastings wrote:
> Following up on a conversation on python-dev from last December:
>     http://mail.python.org/pipermail/python-dev/2012-December/122920.html
> I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
> into the CPython source tree.
>     http://www.python.org/dev/peps/pep-0436/

The PEP gives an internal, developer-focused rationale. I think there is 
also an external, user-focused rationale. As much as possible (with 
obvious caveats about type introspection), I think it should be 
transparent to users (other than speed) whether a function is 
implemented in Python or C. People who love keyword calling currently 
have to learn which module by module and function by function. 
Tranparency will become even more important as more modules are dual 
coded, and as users move code between implementations. I presume some of 
the complexities of  PyArg_ParseTupleAndKeywords arise from pursuing 
this goal. And if I understand correctly, this PEP should reduce some of 
the complexities. The 'future goal' of C function signature info will 
further aid transparency.

This user rationale suggests that positional-only functions should be 

It also suggests another future goal: a clinic backend that would 
instead output a skeleton python file with def header lines and 
docstrings, leaving the bodies to be filled in. One could also wish for 
the opposite: a python file processor that would convert def header 
lines and docstrings to a skeleton C file with clinic specifications.

 > Do we need to support tuple unpacking?

Well, Python 3 dropped that for python functions, so it is not needed 
needed for conversions to or from python 3 files. I suspect the same 
rationale applies to C as well as Python functions: the unpacking can be 
done explicitly in the body, as needed.

Terry Jan Reedy

More information about the Python-Dev mailing list