Home Original page

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