Well, I’ve gone and done it. Thanks to David Malcolm’s excellent 2to3c tool and some hand wrangling with PyUnicode objects I was able to get D-Bus Python compiling and working on Python 3. Grab the patch and start testing it out.
I’ve also tested this under Python 2.6 but it would be nice to see if it also works under Python versions < 2.6 since 2.6 has a couple of compatibility layers built in.
[read this post in: ar de es fr it ja ko pt ru zh-CN ]
Good to see – it’s been frustrating how little adoption of Python3 there’s been among open-source projects. It’s been out over a year, yet there are still no Gtk+ bindings, nor even a hint that they’re being worked on…
Comment by Simon — February 3, 2010 @ 8:42 pm
David Malcolm just moved over to the Fedora Team inside Red Hat and is working to get Fedora Python 3 ready by F13. I’m not sure it is going to happen that soon but there should be a parallel installable environment by then. Once the distros start shipping Python 3 modules should move over more quickly. The issue is it isn’t an easy fix and since Python 2.x is such a great piece of software, there is no real rush to move.
I think with GTK+ we are more focused with GNOME 3 right now. My best guess is GTK+ for Python 3 will follow the JavaScript bindings and be generated mostly from the introspection data. I’ll have to follow up with Johan Dalin to see what his thoughts are there.
Comment by J5 — February 3, 2010 @ 8:56 pm
Like the Python 3 porting guidelines says, it would be nice if the gtk bindings would be ported to Py 3 without API break. This is explicitly mentioned in the porting guidelines since it’s unworkable if everyone decides to ship API changes together with the forward-port of python version — it makes the task must harder for all applications using pygtk.
Comment by ulrik — February 4, 2010 @ 4:20 am
So I stand corrected – here is the progress for PyGtk
https://bugzilla.gnome.org/show_bug.cgi?id=566641
Comment by J5 — February 4, 2010 @ 1:13 pm
The biggest issue I found when porting an extension over to Python 3 was string handling, and I’m not sure automated tools would have helped.
The particular extension I was working on was a binding for GPG and had been using 8 bit strings for UTF-8 encoded data (e.g. the user names on keys), ASCII representations of binary data (e.g. key fingerprints) and actual binary data (e.g. the data being encrypted).
This is the sort of problem that the Python level 2to3 translator has problems with, and the solution was similar too: convert human readable data to the unicode API (or PyUnicode_* in this case), and anything that needs to be binary to the by tes API (or PyBytes_*, which is aliased to PyString_* for 2.x).
Comment by James Henstridge — February 4, 2010 @ 11:57 pm
@James,
Ya, David’s 2to3c code just hits the most common conversions. He leaves the string handling to the module programmer. 2to3c is a good start though. One of the things that would be nice is if it put comments on code that needs to be looked at by the programmer.
Comment by J5 — February 5, 2010 @ 1:23 pm
> good start though. One of the things that
> would be nice is if it put comments on code
> that needs to be looked at by the programmer.
John: interesting; what kind of thing could it detect – string handling uncertainty? Can you file an RFE with some ideas on this in the tracker here:
https://fedorahosted.org/2to3c/
Thanks!
Comment by Dave Malcolm — February 18, 2010 @ 4:52 pm