[Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

Larry Hastings larry at hastings.org
Tue Dec 4 02:21:40 CET 2012

On 12/03/2012 03:42 PM, Gregory P. Smith wrote:
> On Mon, Dec 3, 2012 at 2:29 PM, Larry Hastings <larry at hastings.org 
> <mailto:larry at hastings.org>> wrote:
>     Default
>       values for arguments are represented in C as strings; the conversion
>       process attempts eval() on the string, and if that works it uses the
>       result, otherwise it simply passes through the string.
> I think passing on the string if that doesn't work is wrong.  It could 
> lead to a behavior change not realized until runtime due to some other 
> possibly unrelated thing causing the eval to fail.

Good point.  I amend my proposal to say: we make this explicit rather 
than implicit.  We declare an additional per-parameter flag that says 
"don't eval this, just pass through the string".  In absence of this 
flag, the struct-to-Signature-izer runs eval on the string and complains 
noisily if it fails.

>     * Right now Clinic paves over the PyArg_ParseTuple API for you.
>       If we convert CPython to use Clinic everywhere, theoretically we
>       could replace the parsing API with something cleaner and/or faster.
>       Does anyone have good ideas (and time, and energy) here?
> By "paves over" do you mean that Clinic is currently using the 
> ParseTuple API in its generated code?

Yes.  Specifically, it uses ParseTuple for "positional-only" argument 
processing, and ParseTupleAndKeywords for all others.  You can see the 
latter in the sample output in my original email.

> Yes, we should do better. But don't hold Clinic up on that.

As I have not!

>     But the biggest unresolved question... is this all actually a terrible
>     idea?
> No it is not.  I like it.



More information about the Python-Dev mailing list