Argument Clinic calls one the following functions depending on parameters:

* PyArg_UnpackTuple(), _PyArg_UnpackStack()
* PyArg_ParseTuple(), _PyArg_ParseStack()
* PyArg_ParseTupleAndKeywords(), _PyArg_ParseStackAndKeywords()
* etc.

Would it make sense to emit C code instead of calling complex and slow PyArg_ParseXXX() functions? It would emit the most efficient C code to parse arguments.

I don't recall where this idea comes from. Maybe Larry Hastings told me once that he wants to implement this idea :-) I'm sure that Larry has a big plan but lacks time to implement all of his cool ideas.

Using profiled guided optimization (PGO), the compiler should be able to easily detect that error cases are unlikely and mark these code paths as unlikely.

We should probably experiment an implementation to be able to measure the speedup, to be able to say if the idea is worth it or not, in term of performance, since the motivation here is clearly performance.



We can begin with format strings only made of "O" format. Most simple example with divmod(), replace:

    if (!_PyArg_UnpackStack(args, nargs, "divmod", 2, 2, &x, &y)) { return NULL; }

with something like:

    if (nargs != 2) { _PyArg_ErrNumArgs(nargs, 2, 2, "divmod"); return NULL; }
    x = args[0];
    y = args[1];


The next question is if we should go further with more complex formats. Example with the format() function, replace:

    if (!_PyArg_ParseStack(args, nargs, "O|U:format", &value, &format_spec)) { ... }

with:

    if (nargs < 1 || nargs > 2) { _PyArg_ErrNumArgs(nargs, 1, 2, "format"); return NULL; }

    value = args[0];

    if (nargs == 2) {
        format_spec = args[1];
        if (!PyUnicode_Check(format_spec)) { .. raise an exception ...; return NULL; }
        /* getargs.c calls PyUnicode_READY(), we should also do it here */
        if (PyUnicode_READY(format_spec) == -1) { return NULL; }
    }
    else {
        format_spec = NULL;
    }