[Python-Dev] Python Language Summit at PyCon: Agenda (original) (raw)

Stefan Behnel stefan_ml at behnel.de
Sun Mar 3 11:14:41 CET 2013

Stefan Krah, 02.03.2013 21:01:

Stefan Behnel wrote:

I'm not so happy with the argument clinic, but that's certainly also because I'm biased. I've written the argument unpacking code for Cython some years ago, so it's not surprising that I'm quite happy with that and fail to see the need for a totally new DSL and a totally new implementation, especially with its mapping to the slowish ParseTuple*() C-API functions. I've also not seen a good argument why the existing Py3 function signatures can't do what the proposed DSL tries to achieve. They'd at least make it clear that the intention is to make things more Python-like, and would at the same time provide the documentation.

That's why Stefan Krah is writing a competing PEP - a number of us already agree with you, and think the case needs to be made for choosing something completely different like Argument Clinic I'll happily provide my feedback to that approach. It might also have a positive impact on the usage of Py3 argument annotations, which I think merit some more visibility and "useful use cases". BTW, I think so far no one has stepped forward to implement the custom argument handlers. I've looked at Cython output and, as you say, most of it is there already. Is it possible to write a minimal version of the code generator that just produces the argument handling code?

It should be possible, although it does have a lot of dependencies on Cython's type system, so a part of that would have to be extracted as well or at least emulated. Conversion functions are based on it, for example.

However, I think it would actually be easiest to just let Cython generate the module interface completely. I.e. you'd remove all code that currently deals with Python function signatures from the C module, only leaving the bare C API, and then generate a Cython interface module like this:

cdef extern from *: object original_c_xyzfunc(object x, int y, double z)

def xyzfunc(x, int y=0, *, double z=1.0): "docstring goes here" return original_c_xyzfunc(x,y,z)

Finally, #include the generated C file at the end of the original module. There'd be a bit of a hassle with the module init function, I guess. Maybe renaming it in the Cython C code (even just a #define) and calling it from the original module would work. Or do it the other way round and add a hook function somewhere that does the manually written parts of the module setup. Sounds simple enough in both cases, although I'm sure there's lots of little details. Extension types and their methods are certainly part of those details ...

Stefan

More information about the Python-Dev mailing list