[RFC] dbus-python API (re)definition

[Johan Dahlin]

Simon McVittie wrote:
> 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.

I disagree, ctypes will eventually be forced to be fixed. There are going
to popup lots of python bindings using ctypes.
Either selinux or ctypes will be fixed in the end.

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

I don't really plan to redistribute them or even write applications using
them, so it shouldn't be a problem.

> 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 care about backwards compatibility, there's already (although limited)
support for the dbus binding api.
Ideally it should realize when the old/deprecated API is used and
automatically install/enable it and provide the user with a warning that he
should upgrade to the newer API without breaking the applications.

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

That seems like an API abuse to me.

An object in a D-Bus sense should map to a python object.
To be able to instantiate an object you should to know the type, and to
construct the type you should to know the base types.
It's my personal opinion that this should not be something that should be
encouraged in applications.

Of course, since we're talking python, if we really want to allow this we
could replace __class__ with an updated type which has the new interface
added. It's probably not trivial to find out when these are added and send
a notification to the client.

Johan