PyArg_ParseTuple on steroids?
Phlip
phlip_cpp at my-deja.com
Tue Mar 13 12:47:42 EST 2001
Grant Munsey wrote:
> I have been doing a lot of Python to C library adapters recently.
> Currently I'm generating the code for each Python cover routine with
> a Python program which uses a crude IDL to drive the generator. I
> build the IDL descriptors by hand or with another Python program in
> the case where the API is described in a "regular" way.
>
> Currently the C source that is output by the generator looks pretty
> much like code that would be generated by hand ... with
> PyArg_ParseTuple() at the beginning and Py_BuildValue() at the end.
>
> I was thinking of changing this to have the generator generate a table
> of parameter descriptions for each procedure and one call to an "uber"
> argument handler ... that would check the parameters, get the C values,
> call the function, and convert the results back into a Python return
> value. Kind of a PyArg_ParseTuple(), call function, Py_BuildValue() all
> rolled into one but that could handle many more parameter types than the
> standard routines do.
>
> This would have the benefit of smaller overall code generation and the
> various parameter handlers would be in one place instead of spread all
> over a large Python program which generates code.
>
> Anyone done this in the past and have any advice?
You are "adding epicicyles".
Switch to C-style C++, and use the Boost Python Library. We auditioned many
solutions and skidded to a halt at BPL when we saw how it used C++ style
reflection to identify our function arguments at C++ compile time. No extra
languages or IDL files or anything. We can now RefactorMercilessly our
bindings without risking weird bugs or double-checking everything in
multiple files.
www.boost.org
--
Phlip phlip_cpp at my-deja.com
============== http://phlip.webjump.com ==============
-- MCCD - Microsoft Certified Co-Dependent --
More information about the Python-list
mailing list