dbus-python 0.80rc1 release candidate

Simon McVittie simon.mcvittie at collabora.co.uk
Wed Dec 6 06:50:34 PST 2006


Release candidate 1 for dbus-python 0.80 is now available. Please
download, test, try to break it.

Downloads
=========

Git: tagged 0.80rc1 in
http://people.freedesktop.org/~smcv/git/dbus-python/.git

Source:
http://people.freedesktop.org/~smcv/dbus-python-0.8pre/dbus-python_0.80~rc1.orig.tar.gz

Debian source package, and binary packages for i386, amd64, powerpc, in:
http://people.freedesktop.org/~smcv/dbus-python-0.8pre/

API docs:
http://people.freedesktop.org/~smcv/dbus-python-0.8pre/epydoc/

Compatibility
=============

dbus-python's implementation of the D-Bus binding interoperability tests
will interoperate with dbus-java on i386 and AMD64, and with
itself on at least those platforms plus PowerPC.

Although the API contains incompatible changes, most dbus-python
programs will continue to work (possibly with warnings). A notable
exception is the Python XMPP client Gajim, which uses some extremely old
API which is no longer supported.

It appears the most common source of warnings can be removed by
replacing:

	except dbus.dbus_bindings.DBusException:

with:

	except dbus.DBusException:

This is compatible with dbus-python >= 0.40.2. In practice, I don't
think it's worth supporting dbus-python versions older than about 0.60
(which was released over a year ago).

Changes since 0.80pre1
======================

* 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.

* Bus objects now have get_object_by_unique_name() which resolves
  well-known names to unique names at proxy creation time, meaning that
  signal connections and method calls *won't* follow name ownership
  changes. Use this if interactions with a remote object are stateful.

* 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 a
  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
  dbus.lowlevel.

* 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
  still accepted.

* setup.py no longer removes the ChangeLog on "setup.py clean", since
  the ChangeLog is (and should be) shipped in tarballs.

Other changes since 0.71
========================

* 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
  stub.

* Similarly, dbus_glib_bindings has been rewritten in C as
  _dbus_glib_bindings. Don't use it directly, use dbus.mainloop.glib instead.

* 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.

* Subscripting a ByteArray returns Byte instances.

* 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
  str

* Proxy methods with multiple return values return a tuple rather than
  a list.

* Calling a proxy method with reply ignored, or with async
  handlers, returns None

Regards,
-- 
Simon McVittie, Collabora Ltd.: http://www.collabora.co.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 266 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20061206/9733fada/attachment.pgp


More information about the dbus mailing list