[libvirt] libvirt and python3

Daniel Veillard veillard at redhat.com
Fri Jul 19 14:37:58 UTC 2013


On Fri, Jul 19, 2013 at 09:58:30AM +0100, Daniel P. Berrange wrote:
> On Fri, Jul 19, 2013 at 07:26:09AM +0200, Michal Privoznik wrote:
> > On 19.07.2013 04:04, Doug Goldstein wrote:
> > > On Thu, Jul 18, 2013 at 1:13 PM, Dave Allan <dallan at redhat.com> wrote:
> > >> I've seen a bunch of interest in python3 [1,2,3].  Has anybody started
> > >> thinking about python3 bindings for libvirt?
> > >>
> > > 
> > > While not really answering your question, I would like to see the
> > > build system a little more flexible with regards to Python binding
> > > generation. Currently you have to configure libvirt and it will
> > > generate bindings for the python it detects (or is supplied) and if
> > > you want to change that you need to rebuild the entire source tree.
> > > It'd be nice in the future to be able to build against multiple
> > > Python's without having to reconfigure and rebuild.
> > 
> > That's because python bindings need the client implementation. But I
> > agree that it would be nice if one could just:
> > 
> > make -C python
> > 
> > to build the bindings.

  yes that would be nicer, the problem is that python version
detection is done in configure.ac .

> > To answer Dave's question, I'm not really into python but isn't 2to3 enough?
> 
> 2to3 will take a python2 file & spit out a reasonable python3
> file. The issue is that, IMHO, we don't want to be in the business
> of maintaining 2 sets of python bindings. For any C code, I think
> we want to make sure we use #if conditionals to minimize the extra
> burden of python3.  For the py code, I think we should also aim to
> try to support 2 & 3 with one set of code. There are some modules
> you can import which give you access to some python3 style apis
> from python2, which could help.

  When I ported libxml2, I had to do a couple of tricks but honnestly
not too many, and I didn't try to use any portability layer. On the
other hand debugging a lot of the nasty stuff that 2to3 generated making
it improper for python2 or just changing the semantic wasn't too fun.
That's why if i were to do it now on libvirt I would process from the
set of patches I used for libxml2.

Daniel

-- 
Daniel Veillard      | Open Source and Standards, Red Hat
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list