On Thu, Jul 18, 2013 at 1:13 PM, Dave Allan <dallan(a)redhat.com&gt; wrote: 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. Count this as a "would like to see python 3.x support but don't have time to personally do it." Just a thought. -- Doug Goldstein

On Fri, Jul 19, 2013 at 07:26:09AM +0200, Michal Privoznik wrote: 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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Thu, Jul 18, 2013 at 02:13:59PM -0400, Dave Allan wrote: I'm not going to do any work on it, but I have two requirements here - We should not end up maintaining two separate bindings. We want to minimize the duplication of code to as great an extent as possible, as close to zero extra overhead as possible in fact. The generator will help, but there's still hand-written C code & python code that we really don't want to be duplicating - We should be able to build both python2 & python3 at once. ie you should not need to run ./configure --with-python=2|3, in order to choose. We should detect both python2 & python3 at once & build both if both are available. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Thu, Jul 18, 2013 at 02:13:59PM -0400, Dave Allan wrote: libvirt python bindings are autogenerated for the most part. The tool is inherited from libxml2. I have made the port of libxml2 to be python3 compatible for libxml2-1.9.1 back in April http://xmlsoft.org/news.html there have been a few subsequent patches to that port after 1.9.1 but it's mostly okay. Of course the libxml2 patches won't apply 1-1 to libvirt but the main parts should and i tripped on all the breakage left by 2to3 so we should be able to do that without too much crazyness. Someone contributed the equivalent for libxslt which uses the same system, but I hadn't yet the time to review and process them. I was somehow hoping to do those patches for libvirt but my plate is fairly full ATM. I guess the core work based on my libxml2 set of patches should take me 2-3 full days (as in not doing anything else !), since that wasn't looking urgent, I didn't try to arrange to spend that time, yet... libxml2 of course is compatible with python 2, back to 2.4 ... Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/