[Python-Dev] Announcing PEP 436: The Argument Clinic DSL (original) (raw)

Larry Hastings larry at hastings.org
Tue Feb 26 19:47:30 CET 2013

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

More information about the Python-Dev mailing list