Nick Craig-Wood schrieb:
> Ralf Schoenian <r...@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
--
http://mail.python.org/mailman/listinfo/python-list
