[Python-Dev] Python Language Summit at PyCon: Agenda

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