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

[Terry Reedy]

On 2/26/2013 1:47 PM, Larry Hastings wrote:
> 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

If I were writing something like Clinic, I would be tempted to not have 
that option. But I was actually thinking about something in the 
positional-only writeup that mentioned the possibility of adding 
something to the positional-only option.

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

yes, especially with signatures.
>
>> 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.

Module variables are option few enough to copy by hand. Methods are more 
of a problem. As I understand it, C module files are structured 
something like the following, which is 'unusual' for a python file.

def meth1_impl(...

def meth2_impl(...

class C:
   meth1 = meth1_impl
   meth2 = meth2_impl

So producing an idiomatic skeleton would require more that an alternate 
backend. Rather function entries should be stored and not output until 
the structure (class) definition is encountered. Two passes would be a 
lot easier than one.

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


-- 
Terry Jan Reedy