[RFC] dbus-python API (re)definition

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While ctypes seem a bad plan for the reference implementation of D-Bus on
Python, for the reasons Daniel pointed out, your API redesign is
certainly worth a look.

Since you appear to be unconcerned about breaking API compat, would
it be possible to call your bindings something other than "dbus", so the
two can coexist? "pydbus", perhaps, since you seem to be calling the
project that already? (import pydbus.bus.SessionBus, etc.)

On Thu, 31 Aug 2006 at 14:10:54 -0300, Johan Dahlin wrote:
> * Namespacing. I've deliberately avoided any kind of aliases in the
>   codebase, to make it easier to follow and read the code.
>   That will make it possible to connect the name "dbus.bus.SessionBus" to
>   a package that's called dbus with a module named bus.py with the class
>   SessionBus. Adding aliases makes the end user slightly nicer at the
>   cost of adding a layer of indirection.

I personally prefer this style of Python code (end users should import
names from wherever they were initially defined, and "import *"
considered harmful), but if we care about API backwards compatibility at all,
we're stuck with some variation on the current style. Even though I'm
intending to alter the API, gratuitously breaking common idioms like
"@dbus.service.method(...) def ..." and "from dbus import Variant" seems a
bad move.

> * I added a couple of parts which makes the introspection on the client
>   side more pythonic, it constructs types with methods using the
>   introspection  data, and avoids the "casting" of interfaces which is a
>   problem the current bindings has. This makes dir() in a client side
>   proxy object work as expected.

That's rather nice and we should perhaps try to incorporate it.
On the other hand, it should be possible to use objects before the
introspection reply comes back, and indeed Telepathy contains D-Bus
objects that don't know what interfaces they support until one of their
methods has been called.

>   I suggest that anyone working on the higher level api should take a closer
>   look at some of the python CORBA bindings such as PyORBit which has
>   already solved many of the problems (at a technical level) that the dbus
>   python bindings suffers from.

I'll have a look at those.

Thanks for the feedback,
	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFE9y34WSc8zVUw7HYRAgkVAJ4vdWPriqdUzhkYdLyV6XNSFie0RQCfS0RD
pMPS6gDqZl/Rh/V+UYGBGK0=
=b6Bm
-----END PGP SIGNATURE-----