Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for different event loops via asyncio #57

Open
jas-per opened this issue May 25, 2017 · 4 comments
Open

support for different event loops via asyncio #57

jas-per opened this issue May 25, 2017 · 4 comments

Comments

@jas-per
Copy link

jas-per commented May 25, 2017

currently pydbus has to use glib's mainloop - if you want to use pythons asyncio (trollius on python2) you have to run 2 event loops in your program. fortunately asyncio is designed to use different event loops underneath, so you can replace asyncio's event loop with the glib one by using https://github.com/nathan-hoad/gbulb and have all async code including pydbus run on glib's mainloop

a better solution for pydbus would be to use asyncio as event loop abstraction, so it could be used with any event loop underneath - in addition to the built-in asyncio event loop you can currently choose from uvloop, aiogevent (on top of gevent), tornado and glib

really appreciate the work you're doing for a modern pythonic dbus library - proper support for asyncio would help tremendously in establishing pydbus as the new standard lib for python/dbus

@hcoin
Copy link

hcoin commented Jul 25, 2017

I'm tinkering with the notion of expanding the dbus native 'signal' idea in an expanded pydbus implementation, which would enable the ideas above. See the fork hcoin/pydbus The working notion is: if any property or method call appends an '_async' then it completes immediately returning ever only 'none', with the timeout or completion or error noted in the arguments to function passed at bus.get time.

That, and named arguments. And defaults. And interpretation of bits in integers as tuples of string flags, and, bug fixes that allow pydbus to work on all the major distros, including publishing on glib versions prior to 2.46. All demonstrated with travis CI examples.

And... the novel notion that a dbus services can often be thought of as it's own ecosystem, one that uses argument names consistently within the namespace of a service. So... there's an option that supplies argument defaults from the last known value of that argument name in any use within that space.

That, and: result=dbuservice.method() --> say result position1 has name 'one'

result[1]==result.one==result['one']==result._arg_one == dbuservice._state.one

See much of it at https://github.com/hcoin/pydbus . I've got a big commit coming that implements the service-global argument-name-as-attribute space.

Pydbus is a great idea from Linus. My work is to make it possible for broad acceptance by doing much of the distro specific legwork and adding a few ideas.

@jas-per
Copy link
Author

jas-per commented Jul 25, 2017

great to see so much work python/dbus going on, thanks a lot! I'm currently using https://github.com/ldo/dbussy for event-loop agnostic asyncio dbus, still a bit raw but very promising implemention! bit busy right now, but I'll definitely get more involved this fall/winter

@ldo
Copy link

ldo commented Oct 8, 2017

You may not need to do anything. Try glibcoro to provide the asyncio wrapper for the GLib event loop, and pydbus should be able to work with asyncio-using code unchanged.

@tenuki
Copy link

tenuki commented Feb 19, 2020

You may not need to do anything. Try glibcoro to provide the asyncio wrapper for the GLib event loop, and pydbus should be able to work with asyncio-using code unchanged.

Cool, but, glibcoro refers to gbulb like being the same but more advanced.. and gbulb is unmaintained.. :-(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants