Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Travis Griggs <travisgriggs@gmail.com>
Newsgroups: comp.lang.python
Subject: Confused by python-dbus weird behavior
Date: Mon, 11 Jan 2016 14:14:05 -0800
Lines: 56
Message-ID: <mailman.25.1452550455.13488.python-list@python.org>
References: <4ac97a67-2527-424e-90e2-b714528977c8@googlegroups.com> <mailman.80.1452292120.2305.python-list@python.org> <c0a4d342-f8b5-48a6-b260-89d0458137cd@googlegroups.com> <CAPTjJmptb14bfYG1Ft36rb1OPYTU9CSCqg8rgVgueiAX-Wt0yQ@mail.gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CAPTjJmptb14bfYG1Ft36rb1OPYTU9CSCqg8rgVgueiAX-Wt0yQ@mail.gmail.com>
Precedence: list
Xref: csiph.com comp.lang.python:101496

This may not be a great list for this question (which would be?); it=E2=80=
=99s a big group, and I=E2=80=99m hoping there=E2=80=99s some people =
here that cross into these same areas.

I=E2=80=99m new to dbus, it seems it=E2=80=99s a sort of CORBA for the =
Linux world. :) Python seems to be a popular way to interact with it. =
I=E2=80=99m trying to interact with the BlueZ services for Bluetooth LE =
stuff, and the scant hints I can find seem to indicate dbus is the =
preferred way going forward. The BlueZ distribution even provides =
example code. That said, my question should be independent of whether =
this was BLE or a dbus interface for a Calculator program.

There is a class defined as such:

    class Characteristic(dbus.service.Object):
        def __init__(self, bus, index, uuid, flags, service):
            # =E2=80=A6 set a bunch of attributes
            dbus.service.Object.__init__(self, bus, self.path)

        @dbus.service.method(GATT_CHRC_IFACE, in_signature=3D'ay')
        def WriteValue(self, value):
            print('Default WriteValue called, returning error=E2=80=99)
            raise NotSupportedException()

Then I have a subclass of my own:

    class MyCharacteristic(Characteristic):
        def __init__(self, bus, index, uuid, flags, service):
            Characteristic.__init__(self, bus, index, uuid, flags, =
service)
            # =E2=80=A6 set some of my own attributes

        def WriteValue(self, value):
            print(=E2=80=98Got write value:=E2=80=99, value)
            self.anotherMethod(value)
            print(=E2=80=98back from anotherMethod=E2=80=99)

        def anotherMethod(self, value):
            print(=E2=80=98pondering this value:=E2=80=99, value)

My program does not call WriteValue directly. It seems to be called by =
the bluetooth machinery. The mainloop, or something like that. I don=E2=80=
=99t honestly know. I just know I use some other boilerplate code =
involving registration and the mainloop, to get it all running. And so =
the MyCharacteristic.WriteValue() method DOES get fired. I see the =
output. But when it gets to the anotherMethod call, it just seems to... =
not. More callbacks may fire later. But that=E2=80=99s the end of that =
one. I=E2=80=99ve tried this under python2 AND python3.

So my basic python-dbus question is: Is this some nuance where a =
callback method, inheriting from what looks like a proxy of some sort =
(dbus.service.Object) should/can not send messages to itself?

Help me python-obis, help me. You=E2=80=99re my only hope.