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

[Larry Hastings]

On 02/26/2013 08:11 AM, Terry Reedy wrote:
> 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 
> discouraged.

I think positional-only functions should be discouraged, but we don't 
really need Clinic to do that.  I suppose we don't need Clinic to 
support signatures for built-in functions either, though Clinic would be 
a much bigger help in that department.

So, here's my interpretation of the above suggestion: one user-focused 
rationale for Clinic is that it'll make it easier for developers to 
write built-ins that behave identically to functions written in Python, 
and this benefits users.  Do you agree with that?

> 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.

Well, right now Clinic has no visibility into variables, just 
functions.  So such a skeleton python file would be a bit incomplete.

That's mildly interesting to consider, though--telling Clinic about 
module variables, that is.  Another possible use of Clinic is to do 
conformance testing for alternative implementations, that is, having 
PyPy (for example) make sure that they got their reimplemented standard 
library API correct.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130226/da8864b7/attachment.html>