Status of dbus-python

[Simon McVittie]

On Fri, 14 Aug 2009 at 07:20:26 -0500, Schmottlach, Glenn wrote:
> 
> > (dbus-python does usually use a tiny piece of dbus-glib - the libdbus <-> GLib
> > main loop integration - but that can be replaced by a module provided
> > by the Qt4 Python bindings, or by any other main loop integration shim
> > with the same API.)
> 
> My *wish* would to someday have a Python D-Bus binding that had NO
> dependencies on GLib/GObject.

dbus-python has no dependency on GLib/GObject at runtime. It's only a hard
dependency at compile time for simplicity, and because in practice most of its
users use the GLib main loop glue; it could be made optional if anyone cares
enough.

What it does need (unless you only do blocking calls) is some main loop plugin
implementing a defined API - the only one shipped with dbus-python uses GLib,
but the Qt Python bindings provide one for Qt, which makes the GLib one
unnecessary.

I tried implementing glue for pure-Python main loops a while ago, but didn't
get very far; a C one using libevent or poll() or something shouldn't be
difficult, though. First you need to do your loop <-> libdbus glue (similar
to what dbus-glib has), then you can write a tiny CPython module to hook up
that glue code to the dbus-python connection. The main thing is to tell libdbus
how it can watch a socket, and how it can schedule a timeout, in such a way
as to have its callbacks invoked from your application's main loop at the
appropriate times.

(As long as dbus-python is a binding of libdbus into CPython - as opposed to a
full reimplementation in pure Python analogous to dbus-java or ndesk-dbus -
the main loop glue will have to be done at least partially in C, because you
glue main loops into libdbus via a C API. I was aiming for a simple
C implementation that delegated everything to methods on a suitable Python
object, but never quite got it to work.)

I wouldn't advocate having any sort of default in any case, though - the
choice of main loop has to be a conscious decision by the application
developer (because if they have a GUI, or any other event-driven stuff, they
need to pick the one that their other event-driven code is expecting).

Even if someone implements pure-Python main loop support, that just moves
the problem to "what data structures does the pure-Python main loop use?",
and only the application developer knows which main loop they will be entering
(via glib.MainLoop().run() or asyncore.loop() or whatever). It would be no use
if dbus-python placed its timeouts and sockets into asyncore data structures,
that were then never processed because the application was using the GLib
main loop instead... so, the application developer would still
need to instantiate a (hypothetical) dbus-python MainLoop subclass and tell it,
for instance, which glib.MainContext it should be using.

> Pulling in GLib/GObject for this is overkill and in an embedded
> environment with limited resources an unfortunate choice. Plus, the
> GPL nature of GLib/GObject makes it difficult to use with proprietary
> applications.

The GPL nature that it does not, in fact, have? All the major GNOME libraries
are LGPL, just like glibc.

(It's unfortunate that dbus-python uses dbus-glib for the main loop
integration, admittedly; in principle, it should be able to use only libdbus
and GLib, whereas dbus-glib drags in GObject too, as a result of containing
an object mapping as well as just the main loop integration glue.)

    Simon