[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.
\o/
//arry/
More information about the Python-Dev
mailing list