2

I'm trying to dynamically add signals to a D-Bus service using dbus-python. It provides a decorator for this that works fine if the signal names are known at module load time; however, I don't know what name to export to D-Bus until runtime.

To illustrate the problem, what I'd like to do is the moral equivalent of:

import dbus
import dbus.service
import gobject
from dbus.mainloop.glib import DBusGMainLoop

class Event(dbus.service.Object):
    def __init__(self, name):
        self.name = name
        self.busName = dbus.service.BusName('com.acme.EventManager',
                                            bus=dbus.SessionBus())
        dbus.service.Object.__init__(self,
                                     self.busName,
                                     '/com/acme/EventManager/' +
                                     self.name)

        self.signame = 'com.acme.EventManager.' + self.name

    # THIS DOES NOT WORK: this decorator is parsed before the Event
    # class, and 'self' wouldn't exist here, anyway...
    @dbus.service.signal(dbus_interface=self.signame, signature='v')
    def emit(self, data):
        print "In %s event, got: %s " % (self.name, data)

if __name__ == "__main__":
    DBusGMainLoop(set_as_default=True)
    bus = dbus.SessionBus()
    loop = gobject.MainLoop()
    connect = Event('Connect')
    disconnect = Event('Disconnect')
    loop.run()

Not surprisingly, this generates:

@dbus.service.signal(dbus_interface=self.signame, signature='v')
NameError: name 'self' is not defined

I thought I could just dispense with the syntactic sugar provided by the @ decoration operator and patch Event manually after the class has been defined, something like this:

import dbus
import dbus.service
import gobject
from dbus.mainloop.glib import DBusGMainLoop

class Event(dbus.service.Object):
    def __init__(self, name):
        self.name = name
        self.busName = dbus.service.BusName('com.acme.EventManager',
                                            bus=dbus.SessionBus())
        dbus.service.Object.__init__(self,
                                     self.busName,
                                     '/com/acme/EventManager/' +
                                     self.name)

        self.signame = 'com.acme.EventManager.' + self.name

    def emit(self, data):
        print "In %s event, got: %s " % (self.name, data)

if __name__ == "__main__":
    DBusGMainLoop(set_as_default=True)
    bus = dbus.SessionBus()
    loop = gobject.MainLoop()
    e1 = Event('Connect')
    e1.emit = dbus.service.signal(dbus_interface=e1.signame,
                              signature='v')(e1.emit)
    loop.run()

This runs without errors, but it fails to export the signals to D-Bus. When I run D-Feet, I see the object path /com/acme/EventManager/Connect but it has no interface methods aside from Introspect().

To see if I could learn something about what was going on, I examined the value of the function passed to the dbus.service.signal decorator in a debugger. For this typical use case:

@dbus.service.signal(dbus_interface='com.acme.foo', signature='v')
def emit(self, data):
    pass

the function passed in to the decorator (in the variable func) looks like this:

>>> func
>>> <function emit at 0x99fbed4>

But when I manually invoke the decorator function (as in the the e1.emit = assignment in the second example above), I see:

>>> func
>>> <bound method Event.emit of <__main__.Event at /com/acme/EventManager/Connect at 0x9b3348c>>

So... it seems that, for the normal use case, dbus.service.signal expects to receive a free function---not an unbound function, but a function that, for all intents and purposes, looks like it was defined using:

def emit():
    pass

This behavior is utterly mystifying to me. I've read lots of tutorials on decorators, and thought I understood them pretty well, but I have been stumped on this for hours. If this decorator expects to be called with 'raw' function, how can I convert an object method such that I can invoke it manually?

From this question, I see that types.MethodType() can be used to convert a free function to a bound method. But it seems I need to do the opposite(?)

Community
  • 1
  • 1
evadeflow
  • 4,704
  • 38
  • 51
  • If `dbus.service.signal()` returns a decorator that expects to receive an argument which is a function with no arguments of its own, then you simple can't use it to call your `Event.emit()` method. What does the documentation say about (if all else fails read the source code). – martineau Dec 30 '12 at 08:54
  • The docs say the decorator should be used to "mark methods of a dbus.service.Object to be exported on the D-Bus" [http://dbus.freedesktop.org/doc/dbus-python/api/dbus.service-module.html#signal] – evadeflow Dec 30 '12 at 15:57
  • From the docs and the source it looks to me like the decorator `dbus.service.signal()` returns does handle methods with arguments of their own just fine. I think the problem with doing it manually is that you're passing that decorator `e1.emit` which is a bound method but it's expecting an unbound method because it's actually a _method_ decorator. To do it manually you'd have to pass it `Event.emit` instead of `e1.emit`, but of course that won't work with the way you've defined the `Event` class. To do what you want I think you're going to need to write a class decorator or metaclass. – martineau Dec 30 '12 at 17:04
  • Thanks for the hints, but I'm afraid I'm unable to convert them into a solution. It isn't at all obvious to me why passing ``Event.emit`` won't work. In fact, it's one of the things I tried. This, too, runs without errors, but doesn't work correctly (the object path isn't even registered with D-Bus in this case). I hope that including a short, complete program in my question will allow someone to post an answer with a working solution. – evadeflow Dec 30 '12 at 23:45
  • Sorry, to post a complete working solution would require installing the `D-Bus` package which I am not interested in doing. When you tried using `dbus.service.signal()` with `Event.emit`, what did you use for the `dbus_interface` argument? The problem is in the design of your `Event` class. The decorator is meant to be used in cases of separate subclasses of `dbus.service.Object`, for example see [this](http://dbus.freedesktop.org/doc/dbus-python/api/dbus.service.Object-class.html). – martineau Dec 31 '12 at 04:37

1 Answers1

1

I think one way to do what you want is by using a factory function — however the following is untested because I don't have the D-Bus module installed.

The root of the problem is you're attempting to use a decorator at class definition time that requires data which isn't being provided until instances of that class are created. One workaround for that is to define the class inside a function and use closures so the data is available when needed. Note that the factory function returns instances of the class created, not the class itself, although it could if desired.

import dbus
import dbus.service
import gobject
from dbus.mainloop.glib import DBusGMainLoop

def event_factory(event_name):
    class Event(dbus.service.Object):
        def __init__(self):
            self.busName = dbus.service.BusName('com.acme.EventManager',
                                                bus=dbus.SessionBus())
            dbus.service.Object.__init__(self,
                                         self.busName,
                                         '/com/acme/EventManager/'+event_name)

        @dbus.service.signal(dbus_interface='com.acme.EventManager.'+event_name,
                             signature='v')
        def emit(self, data):
            print "In %s event, got: %s " % (event_name, data)

    return Event() # return an instance of the class

if __name__ == "__main__":
    DBusGMainLoop(set_as_default=True)
    bus = dbus.SessionBus()
    loop = gobject.MainLoop()
    connect = event_factory('Connect')
    disconnect = event_factory('Disconnect')
    loop.run()
martineau
  • 119,623
  • 25
  • 170
  • 301
  • LOL, I _just_ woke up with that same idea. Your solution works perfectly for my current purposes. Thanks for framing it in terms of a _factory function_ and a _closure_, concepts I can readily understand. One undesirable aspect of doing it this way is that the class definition is parsed/stored every time ``event_factory()`` is called, but I hardly care for this rough prototype. If I figure out a way to do it by invoking the decorator manually, I'll post it as an alternate solution. – evadeflow Dec 31 '12 at 13:30
  • If you made the function return the class, effectively making it a class factory (sort of like a C++ template), then you might be able to avoid the overhead of creating the class more than once. However if you only want to create a single instance of one, might as well do it this way. On the other hand being just a class factory means a metaclass could be used. – martineau Dec 31 '12 at 13:51