Extending Python with C or C++

[Thomas Heller]

Nick Craig-Wood schrieb:
> Ralf Schoenian <ralf at schoenian-online.de> wrote:
>>  Ryan wrote:
>> > I've been using Python for many years now. It's a wonderful language
>> > that I enjoy using everyday. I'm now interested in getting to know
>> > more about the guts (C/C++) and extending it. But, extending python
>> > still seems like a black art to me. Is there anymore docs or info on
>> > extending it besides the standard sparse ones (http://www.python.org/
>> > doc/2.5.2/ext/intro.html) that may give me more insight? Is there a
>> > class available? How can I learn more about the guts of python? How
>> > would one go about following an interest in contributing to the
>> > development of python.
>> 
>>  It is not exactly what you are looking for but nevertheless I am 
>>  thinking the  article "Automatic C Library Wrapping -- Ctypes from the 
>>  Trenches" may be interesting for you. You can find it in the latest 
>>  Python Papers issue or simply following the link: 
>>  http://ojs.pythonpapers.org/index.php/tpp/article/view/71
> 
> Interesting - I didn't know about h2xml and xml2py before and I've
> done lots of ctypes wrapping!  Something to help with the initial
> drudge work of converting the structures would be very helpful.
> 
> ( http://pypi.python.org/pypi/ctypeslib/ )
> 
> I gave it a quick go and it worked fine.  I had to edit the XML in one
> place to make it acceptable (removing a u from a hex number).  The
> output of xml2py was an excellent place to start for the conversion,
> though I don't think I'd want to use an automated process like in the
> paper above as its output needed tweaking.
> 
> ...

If you are using a recent version of gccxml, then you should use the
ctypeslib-gccxml-0.9 branch of ctypeslib instead of the trunk. (I should
really merge the gccxml-0.9 branch into the trunk;-)

If you are already using the branch and the XML file is not accepted,
then could you please provide a short C code snippet that reproduces
the problem so that I can fix it?


> Here are my thoughts on the conversion :-
> 
> It converted an interface which looked like this (the inotify interface)
> 
>     struct inotify_event {
>         int      wd;       /* Watch descriptor */
>         uint32_t mask;     /* Mask of events */
>         uint32_t cookie;   /* Unique cookie associating related
>                               events (for rename(2)) */
>         uint32_t len;      /* Size of name field */
>         char     name[];   /* Optional null-terminated name */
>     };
> 
> Into this
> 
>     class inotify_event(Structure):
>         pass
>     inotify_event._fields_ = [
>         ('wd', c_int),
>         ('mask', uint32_t),
>         ('cookie', uint32_t),
>         ('len', uint32_t),
>         ('name', c_char * 0),
>     ]
> 
> Which is a very good start.  However it defined these which clearly
> aren't portable
> 
>     int32_t = c_int
>     uint32_t = c_uint
> 
> Whereas it should have been using the ctypes inbuilt types
> 
>     c_int32
>     c_uint32

IMO this would be difficult to achive automatically.  There are cases
wher c_int is the correct type, in other cases c_int32 is correct.

> Also I don't think c_char * 0 does anything sensible in ctypes,
> c_byte * 0 is what is required plus a bit of casting.  This is a
> non-standard GNU extension to C though.
> 
> All that said though, it looks like a great time saver.
> 

Thanks,
Thomas