|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH,v2]: add libxl python binding
On Fri, 2010-09-10 at 16:49 +0100, Gianni Tedesco wrote:
> Changes since v1:
> - Interpret keyword arguments in initializers: eg. xl.device_pci(bus=1,
> dev=2, fn=3)
> - Implement domain pause/unpause/rename/pci_add/pci_del and pci_parse
> - Proper type-checking in all (I hope) code-paths
> - Improve API for accessing auto-generated code and types
> Changes since RFC:
> - split auto-generated code in to c and h files
> - un-break the build system
> - fix ocaml binding due to libxl API change
> - lot's of tidy-ups too numerous to mention
>
> -----8<---------------------------------------------------------------
> Introduce python binding for libxl. The binding is not yet complete but
> serveral methods are implemented and tested. Those which are implemented
> provide examples of the two or three basic patterns that most future
> methods should follow.
>
> Over 5,000 lines of boilerplate is automatically generated to wrap and
> export all relevant libxl structure definitions. There are a few places
> where such code cannot be fully auto-generated and special hooks are
> declared and stubbed where, for example, conversion between
> libxl_file_reference and a python file object is required.
I'm not qualified to comment on the actual generated bindings themselves
but the tiny bit which remains looks good to me.
One perhaps interesting tip:
> + funcs="""static void Py%s_dealloc(Py_%s *self)
> +{
> +%s self->ob_type->tp_free((PyObject *)self);
[...etc...]
> +}
> +"""%((ty.rawname, ty.rawname, dtor) + tuple(ty.rawname for x in range(5)))
String formatting in python can take a dictionary and then %(foo)s will
expand by looking for the key 'foo' in the dict which would likely
simplify (and help self-document) stuff with this pattern and get rid of
the "x in range 5" stuff. I bet you had a hell of a job lining up all
the %s's with their arguments correctly ;-)
e.g.
"""static void Py%(rawname)s_dealloc(Py_%(rawname)s... etc
""" % {'rawname': ty.rawname, 'dtor': dtor... etc}
etc
I also think you could get rid of the long """ string containing hand
written helpers by putting all that stuff in a pyxl.h and/or xl.c. I'd
much prefer to edit the hand-written C code in a .h file where syntax
highlighting will work properly etc. If you generate the relevant
prototypes correctly then declaration shouldn't be too much of an issue.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|