[Pyrex] Header file/declaration redundancy
Conrad Steenberg
conrad at hep.caltech.edu
Wed Oct 26 17:45:53 CEST 2005
Hi Greg et al.
I've been using SWIG and Pyrex for quite a while now, and there is
something that still bites me regularly:
When generation a binding for some C library code, both tools require
that you look at the header files, and essentially copy the declarations
of functions and data structures to the Pyrex/SWIG binding code.
E.g. I have a binding for the tdb database (tdb.sf.net) with code like
this:
cdef extern from "tdb.h":
ctypedef enum TDB_ERROR:
TDB_SUCCESS = 0
TDB_ERR_CORRUPT = 1
etc.
This seems rather redundant, and even worse, if the tdb declarations
change slightly, the above needs to be kept up to date manually.
Now, I understand the need to declare that certain symbols need to be
made available outside of the Pyrex-generated module - e.g.
tdb.TDB_SUCCESS in this case. But having to retype all the individual
type definitions, struct members etc. simply duplicating what is already
in the header file, tends to be quite error prone.
I love the way that for an opaque struct I don't need to go to the
header file and retype all of it's members, and can just declare it,
e.g.:
ctypedef struct tdb_lock_type:
pass
In other words, it is obviously essential to declare which symbols
should be made available to Pyrex code, or exposed as module symbols,
but it seems that Pyrex code can be made a lot more robust by not having
to retype all the definitions from included header files.
Any comments?
Conrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2531 bytes
Desc: not available
Url : http://lists.copyleft.no/pipermail/pyrex/attachments/20051026/d5a1eedc/smime.bin
More information about the Pyrex
mailing list