dbus-python 0.80.0, the "Everything changes" release
simon.mcvittie at collabora.co.uk
Wed Jan 24 07:57:09 PST 2007
-----BEGIN PGP SIGNED MESSAGE-----
dbus-python 0.80 is now available.
Updated documentation: http://dbus.freedesktop.org/doc/dbus-python/
Although the API contains incompatible changes, most dbus-python
programs will continue to work (possibly with warnings). I've been in
touch with the authors of some of the dbus-python apps known to have
problems (Gajim, GnomeOSD).
Changes between 0.80rc4 and 0.80.0 final
* Install dbus-python.h in $includedir/dbus-1.0/dbus, the same place
libdbus and dbus-glib put their headers
* Improve logic for detecting whether to build documentation
* Remove various desirable-but-unnecessary rst2html flags if not supported
* Don't insist on such a new version of dbus (0.93, as in Ubuntu 6.10 and FC6,
should be fine - our "make check" passes in Ubuntu 6.10)
Changes between 0.80rc3 and rc4
* Finish implementing deferred methods: when called asynchronously,
actually behave asynchronously
* Remove get_object_by_unique_name (introduced in 0.80rc1) and replace
it with a keyword argument follow_name_owner_changes to get_object:
the default is now to *not* follow name owner changes, because the
possible failure mode is less confusing that way round
* Add special case to serialization: objects with a __dbus_object_path__
attribute are serialized as that object path. Add that attribute to
ProxyObject, dbus.Interface and dbus.service.Object.
* byte_array[n], where byte_array is a dbus.ByteArray, returns a str
of length 1 again (this matches 0.71 behaviour, rather than that
of previous 0.80 release candidates)
* Allow running without a main loop if not doing anything asynchronous
(mainly for convenience in the interactive interpreter)
* Further improve Python 2.5 compatibility by using Py_ssize_t
* Considerably more documentation, including an unfinished tutorial
(already more complete than the Python section of the D-Bus core
tutorial, I think)
* More tests and bugfixes, mainly in error paths
Changes between 0.80rc2 and rc3
* The build system uses the GNU autotools instead of distutils, for more
reliable builds during development (distutils doesn't track .h
* dbus-python has been tested with Python 2.5, and now works. It also
now works with Python 2.4 versions older than 2.4.2rc1, although
it will be slightly less efficient on those versions.
* dbus-python.h (formerly dbus_bindings.h) is installed. Packagers
should include it in the dbus-python RPM or .deb - it
can be used to build third-party main loop integration.
* The introspection parser uses pyexpat (which is bundled with Python
and present in a standard build) rather than libxml2 (which is not).
* "make check" runs the cross-test as well as the older regression
tests. The regression tests have also been improved.
* The utf8_strings and byte_arrays options now work correctly when
making async method calls.
Changes between 0.80rc1 and rc2
* Weak reference handling was completely wrong in 0.80rc1. Oops. It now
* Shared bus connections are strongly referenced (kept alive long-term),
so signal handlers don't fall off. They're removed from the table of
shared connections on close().
* If you just do "import dbus" (and not "import dbus.types"), saying
"dbus.types.Int32" and "dbus.exceptions.DBusException" now works again;
it did in 0.71, but didn't in 0.80rc1. This is for compatibility with
Sugar; I'm not sure whether this should work or not, so this change
might be reverted in future.
* The _dbus_bindings module is written with multiple .c files (rather
than a single .c file and the majority of the code in *-impl.h), for a
less surprising code structure. Numerous formerly-static symbols have
been renamed to avoid namespace pollution.
* The examples from dbus/examples/ are now in examples/. All except the
GConf examples have been updated. The GConf examples didn't work in
0.71 and still don't, although they do now print a message on startup
warning that this is the case.
* The explicitly_pass_message decorator has been removed (in rc1 it was
present but had no effect).
Other changes since 0.71
* Signal matching has been completely rewritten. If a well-known name
(as opposed to a unique name) is passed to add_signal_receiver,
or connect_to_signal is used on a well-known-name-based proxy,
signal matching will follow name ownership changes.
* You can disconnect from signals. It works and has test cases. \o/
* add_signal_receiver and connect_to_signal return a SignalMatch object
with a remove() method, which can be used to disconnect signal matches in=
reliable and easy way.
* Low-level (message-oriented) methods are back to being public,
with changed names (containing _message_). Supporting classes (e.g.
SignalMessage and PendingCall) are exposed in a new public module
* There is a workaround for the dbus_pending_call_set_notify race recently
pointed out by Alexander Larsson.
* Main loop integration uses a new API which can be extended to
incorporate pure-Python main loops without breaking anything.
Currently, GLib is still the only usable main loop.
* The dbus.service.Object constructor accepts a Connection instead of a
BusName as its first parameter, so you can export objects even if you
don't have a well-known bus name (making Wladimir van der Laan's
recent patch unnecessary). For backwards compatibility, a BusName is
* setup.py no longer removes the ChangeLog on "setup.py clean", since
the ChangeLog is (and should be) shipped in tarballs.
* The old dbus_bindings (in Pyrex) has been rewritten in C and renamed
to _dbus_bindings. No user-serviceable parts inside. All user code
should use dbus and its various submodules.
* dbus_bindings still exists as a deprecated backwards-compatibility
* Similarly, dbus_glib_bindings has been rewritten in C as
_dbus_glib_bindings. Don't use it directly, use dbus.mainloop.glib instea=
* The Variant class no longer exists. Instead, all D-Bus data types have
a read-only variant_level attribute, which can be set in the constructor.
* Data type mapping between D-Bus and Python has been tidied up.
Conversion from Python to D-Bus is more lenient and will generally do
what you expect in any reasonable situation. Conversion from D-Bus to
Python always produces D-Bus-specific types (subclasses of the usual
Python types) so you can tell exactly what was in the message.
See the API documentation for dbus.lowlevel.Message for details.
* The D-Bus integer types (dbus.Int32, etc.) are properly range-checked.
* The Array constructor takes arguments (iterable[, signature])
rather than (iterable[, type][, signature]); ditto for Dict.
* dbus.Byte accepts a single-byte string passed its constructor, and its
str() returns a single-byte string. It's still a subclass of int.
* The method decorator, all proxy methods, and all three ways to connect
to a signal now have keyword arguments utf8_strings and byte_arrays:
utf8_strings: instead of converting D-Bus strings into Python
dbus.String (subclasses unicode), convert to Python dbus.UTF8String
(a new class subclassing str)
byte_arrays: instead of converting D-Bus byte arrays into Python
dbus.Array of dbus.Byte, convert them to dbus.ByteArray, a subclass of
* Proxy methods with multiple return values return a tuple rather than
* Calling a proxy method with reply ignored, or with async
handlers, returns None
Simon McVittie, Collabora Ltd.: http://www.collabora.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net
-----END PGP SIGNATURE-----
More information about the dbus