D-Bus code is incompatible with forthcoming dbus-python 0.80, and uses non-public API (#2784) · Issues · gajim / gajim

D-Bus code is incompatible with forthcoming dbus-python 0.80, and uses non-public API

I'm currently working on a rewrite of the dbus-python bindings, replacing the Pyrex module dbus_bindings with C code and changing the API where necessary to make the bindings more Pythonic. In practice, most Python D-Bus apps will continue to work with my rewrite, which is going to be released as version 0.80 (I released 0.80rc2 today).

However, the D-Bus code in Gajim uses some interfaces which were never meant to be part of the public API; these will stop working with dbus-python 0.80. The attached patches (untested) should at least get you started on porting gajim to dbus-python 0.80, in a way that will still work on dbus-python 0.60.

Specific issues:

dbus_bindings is not public API, and will go away. You can address most of this by just replacing "dbus.dbus_bindings.DBusException" with "dbus.DBusException" (this works in something like 0.40 and up).
In the remote control, you seem to be emitting signals using a much lower-level interface than is intended. The normal way to do this is by decorating a function of the same name as the signal with dbus.service.signal, then calling it (see my patch).
There is no such thing as None in the D-Bus world. You seem to represent it as the integer 0, which seems likely to cause confusion in future!
In general, it's unclear what you intend the signature of signals and methods to be. Part of designing a D-Bus interface is specifying the types of the arguments and return values for your methods and signals - see the Galago notifications spec (http://www.galago-project.org/specs/notification/0.9/x408.html) or the Telepathy spec (http://telepathy.freedesktop.org/spec.html) for some good examples.
The API for Variants has changed - there's no longer a Variant class, to make method arguments and return values consistent and unambiguous. Marking dicts and arrays with a signature that includes 'v' should achieve what you want to do.

Specific issues:

* dbus_bindings is not public API, and will go away. You can address most of this by just replacing "dbus.dbus_bindings.DBusException" with "dbus.DBusException" (this works in something like 0.40 and up).

* In the remote control, you seem to be emitting signals using a much lower-level interface than is intended. The normal way to do this is by decorating a function of the same name as the signal with dbus.service.signal, then calling it (see my patch).

* There is no such thing as None in the D-Bus world. You seem to represent it as the integer 0, which seems likely to cause confusion in future!

* In general, it's unclear what you intend the signature of signals and methods to be. Part of designing a D-Bus interface is specifying the types of the arguments and return values for your methods and signals - see the Galago notifications spec (http://www.galago-project.org/specs/notification/0.9/x408.html) or the Telepathy spec (http://telepathy.freedesktop.org/spec.html) for some good examples.

* The API for Variants has changed - there's no longer a Variant class, to make method arguments and return values consistent and unambiguous. Marking dicts and arrays with a signature that includes 'v' should achieve what you want to do.