Support asynchronous calls (#58)

[poncovka]

Added support for asynchronous calls of methods. A method is called synchronously unless its callback parameter is specified. A callback is a function f(*args, returned=None, error=None), where args is callback_args specified in the method call, returned is a return value of the method and error is an exception raised by the method.

Example of an asynchronous call:

def func(x, y, returned=None, error=None):
  pass

proxy.Method(a, b, callback=func, callback_args=(x, y))

[jkonecny12]

This would be really valuable for our use case. Could this be merged please?

[johan-bjareholt]

This is a blocker for me, without this I cannot switch from python-dbus to pydbus and then switch over to python3. @LEW21, please take a loot at this PR!

[jkonecny12]

@johan-bjareholt in case you are using Fedora distribution it is packaged with this patch there. It would be great to have it in upstream, however the maintainer here is too unresponsive :(.

[johan-bjareholt]

@jkonecny12 Oh, thanks for the tip. Sadly I'm stuck with a debian environment for this project though.

[M4rtinK]

@jkonecny12 Oh, thanks for the tip. Sadly I'm stuck with a debian environment for this project though.

In any case, these are the patches we apply on top of the Fedora package:

https://src.fedoraproject.org/rpms/python-pydbus/tree/master

[SpotlightKid]

I also would like to switch from python-dbus to pydbus but until asynchronous calls are supported I can't. Please review and, if possible, merge this PR and make a new release.

[SpotlightKid]

Just a friendly reminder, asking to look at this PR and, if possible, merge it and make a new release.

Or, at least, if this project is not actively maintained anymore, make a prominent note of it in the readme.

[marioortizmanero]

It really seems inactive, someone should make a fork to keep this alive

[SpotlightKid]

I just wrote a personal email to the repo owner, asking him basically the same as in my comment above.

[marioortizmanero]

Any news?

[SpotlightKid]

No, my email to the maintainer remained unanswered.

[marioortizmanero]

Should we do anything then? This has been inactive for 2 years. I'm not experienced enough to contribute myself but it'd be great to think about creating a new fork.

[SpotlightKid]

A fork happens if someone has the knowledge and the will to create and maintain it. I'm certainly not that person, since I'm neither an expert on D-Bus nor pygobject.

I'll continue using python-dbus.

[poncovka]

Hi, we are using a patched version of pydbus with some additional support for DBus objects. I am currently working on a complete replacement of pydbus in our project. Then we would like to take all that DBus related stuff and create a new library from it. The basic usage should be the same as with pydbus, but the extensibility should be much better. Unfortunately, a fork of pydbus will not help with that.

[SpotlightKid]

@poncovka That's good to hear. When you publish you project, it would be nice to leave a link here.

[FelixSchwarz]

Not sure if it helps but I'm using jeepney with good results together with a custom gevent-backend. Jeepney also has an asyncio backend and it is pretty easy to hook a custom "loop". Jeepney is also MIT licensed and the author was very responsive. Maybe worth another look?

[poncovka]

It's been a while since we've switched from pydbus to dasbus (https://github.com/rhinstaller/dasbus). The library is stable and well tested, so it could make other people happy. Here is a link to the main differences: https://dasbus.readthedocs.io/en/latest/pydbus.html